Problem Saving ALSA Settings

[Drew]

Update:

I installed a web browser on TC just for something that would help me become more familiar with the file structure of TC.  I know, I know, call me a button pusher, but it works.  While drilling down through the files, I did indeed become a bit more familiar with where stuff is stashed.  But I am still unfamiliar with how certain directories relate to one another.  That said, I found 2 places that might be relevant to this issue, perhaps it will help you determine where exactly I need to put the /libao/libao.conf file.  And I need to verify that it is either going to be /.libao or /libao.

First I noticed /usr/local/lib/alsa-lib/.  In this directory there is the smixer folder and nothing else.

The other path I saw was /usr/lcoal/share/alsa/alsa.conf.d/ and in that directory there was a README file that said the following:

"You can place files named *.conf in this folder and they will be processed when initializing alsa-lib."

I still have not run across any particular directory called /libao or /.libao.  I assume that that needs to be created still, but all attempts to create that directory and the subsequent file, libao.conf in the places you have specified still have not resulted in a sound resolution with rdesktop.

Does the above information clarify anything that might help resolve the issue?  I have been chugging away at this on and off as I can.

[iceman9t9]

Drew

I have been battling same path as yourself. TC is in most other respects looking like the perfect thin client solution for us. However we need sound to work. I am dalso getting the "no working audio driver" found error message. If I find the answer I will post it here. If you have made any further progress then please let me know.

[Juanito]

the libao extension only contains the following plugin:

/usr/local/lib/ao/plugins-4/liboss.so

If it had been compiled to support alsa, I'd expect to see (ref the corepure64 version of libao):

/usr/local/lib/ao/plugins-4/libalsa.so

Perhaps you could pm the maintainer and request they update the extension to support alsa (and pulseaudio)?

[Drew]

iceman9t9,

I most certainly will post any progress I make.  So far, none.

Juanito,

Should I take your post to mean that if I actually install oss instead of alsa, then sound should work?  If so, I've tried that, and am still getting the same messages, and no sound.  Although, it's been a bit since I've been able to spend any time on this.

[Drew]

iceman9t9,

I little further on my overall progress, I actually have one unit being used, without sound of course.  It isn't high profile, or heavy usage, but I have full confidence that it will do great.  Only other issue I'm battling is being able to view it, and control it remotely in case I need to train a user at a branch location.  Installed tightvnc, and can connect to the it, but get a garbled view.  Will probably start a thread on that if I don't find a resolution, and not before looking at other posts on tightvnc.  I took a read on the app documentation when installing it, which helped some.  But obviously, I'm missing something yet.

[iceman9t9]

Thanks for the update Drew. We have now gone live with our tincore implementation. Our workaround for maintaining the remote "zombie" PCs (as we refer to the machines that now boot of a tinycore USB stick) is two fold. When Tincycore boots it sets the hostname to the mac address. It then attempts to download a mydata.tgz file from a specified location which based on the device mac address. This will not exist on first boot. When users login into our terminal server a script run and creates a folder using the machines host name (ie mac address). It also records the name/account the user looged in with. That way we can find the machine a user logins in from and drop a new mydata.tgz file into the matching folder for the machine to download at next boot.

We have alsa sound working on the local device but not from terminal server. We are using Windows 2008 R2 in 64 bit. I am determined to get this cracked.

                   .....                                                 
                 C C  /                                                 
                /<   /     
 ___ __  /_#_/
/(- /(\_\______\     
/|\ /|\      \o     \
               |'     |                                                   
   

[Drew]

Hi Iceman9t9

Once we get things configured exactly like we want, we have the thin clients set to boot on LAN.  A fog server control panel is presented for a few moments, but if the user does nothing it will simply boot into TC.  But at the fog screen, we can register a device, create an image, etc.  Hopefully, we can build a fully working image.  Like you, I'm not overly thrilled with how the security is managed.  I really should say, I'm not as familiar with it, so we have to learn some things there.  Like you, getting sound to work on the thin client with ALSA is a no brainer, but passing sound from the server to the thin client is another story.  It works perfectly on Ubuntu.  But as mentioned here, perhaps alsa is just not supported with this rdesktop.tcz.

We started using thin clients some years ago, and they got bad press.  But trying to explain to the users that their poorly implemented Windows desktop environment (low provisioned apps servers, and other issues) had nothing to do with the thin client itself, is like talking to a wall.  Further, when we upgraded to 2008 R2, the rdp client that came packed in with these Igels was out of date and simply won't connect to server 2008R2, no matter how low we dropped the security settings server side.  It's even a problem with Win XP unless you update the terminal server client.  That's not easy to do with the Igels.  Might as well just throw another OS on there, which is where we're at now.

Now that TC has a fairly updated version of rdesktop, we can connect just fine.  Now it's time for us to provision our server stack to give a user everything they need to do their job, and some times they watch product knowledge videos which requires sound.  So this is something I would love to see solved as well.

[ananix]

Working on same project and have same problem, I have made two keys now one with working OSS and one with ALSA, both also having libao installed.

experimenting with command -r sound:local:oss, -r sound:local:alsa and sound:remote ...... leads me to the arguments is working but when local it always crashes with

ao_oss ERROR: Unrecognized channel name "#"¤%¤GARBAGE CHARACTERS!"#"!" in channel matrix "#!"#GARBAGE CHARACTERS¤#"%"
ao_oss WARNING: Input channel matrix invalid; ignoring.
rdesktop segfaults.....

I found others with same problem but with other programs, one placed it was fixed with removing a kernel module and i also have this

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591396

Can we use that to figure out if rdesktop have same problem or to get closer for the root cause of unrecognized channel name?

I cant seem to find the src for libao in the repo so hard to tell how it was compiled....

Did anyone try to compile rdesktop from newest source?

I think thats my next step....

Hope we can help each other figure this out

  -- Regards Andreas

[Juanito]

I cant seem to find the src for libao in the repo so hard to tell how it was compiled....

see http://repo.tinycorelinux.net/5.x/x86_64/tcz/src/libao/compile_libao for the corepure64 extension, but it looks to be like the x86 extension was compiled without alsa support...

[Drew]

I hope we can get a resolution as well.  I'm not sure how much help I'll be, other than saying that it works perfectly on Slacko Puppy 5.7.  But if I really wanted to standardize on Puppy, I would have done so long ago.  While Puppy is indeed small considering all the apps that come with it, it is still way to big for the hardware space we currently have on our thin clients.  At the end of the day, i don't want my users having access to all those apps locally anyway.  That's why we like to point them to servers that are much more easily updated, and managed.

We are currently using a couple of Tinycore thin clients in the field, but I'm not making a lot of noise about them, until we can present a fully functional desktop environment to the user.

[ananix]

You need to compile rdesktop yourself, the rest of the packages works fine from the repo.

install ALSA
install libao
install libao-dev
install compiletc
install Xorg-7.7-dev
install openssl-1.0.0-dev.tcz

get the newest rdesktop from sourceforge

sudo ./configure --prefix=/usr/local --disable-credssp --disable-smartcard
sudo make

./rdesktop -r sound:local -u "" -f $HOSTNAME

As soon as i tried compile my self it was obvious and i ended up spending 20min with compile to solve the issue.

[Juanito]

As said above, before that, libao probably needs to be re-compiled to support alsa

[ananix]

Not for me it didnt i only had to recompile rdesktop

[Fleepuk]

Hi to all,

Thank you all for giving all the snippets required for getting sound working via rdekstop with connection broker.

I was having problems with the redirection not working from the connection broker having followed ananix's build instruction.  Sound was AOK though.

glibc-gconv was the missing module.  Now its working like a charm.

So, we have a tinycore usb boot key that works on 99% of our legacy hardware, updates itself, handles multiple screens, registers itself and will let us stream sound.  All from one image!

Tinycore is fantastic. As are these forums.

Thank you, thank you, thank you.