Tiny Core Linux
Tiny Core Extensions => TCE Q&A Forum => Topic started by: Drew on February 17, 2014, 08:51:06 AM
-
Hello,
Got ALSA working good, however, I can not get settings to stick upon reboot. I tried the steps given in first post of the following thread, but still running into errors with the usr/local/etc/asound.state file not being found when trying to reboot:
http://forum.tinycorelinux.net/index.php?topic=13885.0
Any ideas? I'm sure I'm missing a step, but have yet to find it.
-
What version are you running?
For Core 5.x the file you need to add to /opt/.filetool.lst is
var/lib/alsa/asound.state
You need to run 'alsactl store' first though.
-
Ah, didn't pay attention to that detail. Performed a do-over with the correct path, and all is good now. Thanks.
On another sound note, I'm having an issue with rdesktop passing sounds to the local host/thin client that I've been working with. I've tried the "-r sound " the "-r sound:local" and also added :alsa to the end of the -r value. Keep getting the "no working audio-driver found" in the terminal window after disconnecting from the .rdp session. I saw this thread, but looks like it hits a wall, and no resolution is found. Should I start another topic, or is this perhaps a continuation of an ALSA issue? I am running an Ubuntu based box as well, and I can turn sound on by simply including the "-r sound" value in the rdesktop string.
Here's the thread:
http://forum.tinycorelinux.net/index.php?topic=15452.0
-
Maybe this will help:
http://www.gearhack.com/Forums/DisplayComments.php?file=Computer/Linux/Getting_Sound_Through_rdesktop
-
Hi gerald_clark
Thanks for the link, but nothing I haven't tried already. The "no working audio-driver found" error that rdesktop puts out upon disconnect is curious to me. Could it be that I need to be even more specific in pointing out the alsa driver to rdesktop somehow? I saw the "-r sound:local:alsa" value, and have already tried that, but to no avail. Again, just adding "-r sound" to the rdesktop string in Ubuntu for the same remote server works beautifully, with no evidence of any backend errors. Both TC and Ubuntu running same version of rdesktop.
-
I've been pecking away at this since my last post, and still no sound from the client when connecting via rdp to a server I know is correctly configured to make sound events available to the client. Again, connecting to the same exact server via rdesktop on an Ubuntu station works perfectly fine with just the "-r sound" parameter entered in the rdp string. I do notice one difference that may be key to this. When I look at the rdesktop help, it gives a great bit of helpful information on how to control various aspects of the connection. So looking at the -r sound section, it points to available driver as alsa on the Ubuntu box. On the Tinycore thin client, it says libao is the available driver. Shouldn't that also say ALSA?
I am also of the thought that my -r string might need to be more specific than just "-r sound" but that's what works on Ubuntu. Hopefully, this additional information is of use. Again, if I need to start a new topic, I will do so gladly, but figured this still may be related to ALSA.
-
Did you read the man page in the rdesktop-doc.tcz?
-
Yes, not as helpful as the help screen that comes built-in to rdesktop, as it pertains to sound parameters. As I mentioned before, I'm trying to make sense of two different setups -- specifically as to why one works (Ubuntu), and one doesn't YET (Tinycore). Both have the same documentation, and say exactly the same thing. Both are running rdesktop 1.7.1. As I noted in my previous post, the one key difference that I see in rdesktop itself, is what is listed as available sound driver. With TC, it says libao. With Ubuntu, it says ALSA.
When I just use "-r sound" in the rdesktop string for TC, it now kills my remote session, and brings me back to terminal window, and references ao_oss errors and warnings, and invalid input channel matrix, and seg fault, etc. This is what makes me think my sound parameter might be incorrect, BUT I'm not having any success in getting that string correct if it is indeed wrong. Documentation is admittedly a bit confusing. I am further confused as to why the simply "-r sound" works perfectly on another work station.
-
It may be that this version was compiled without alsa support.
You need to ask the extension authors.
-
I will try that, thanks.
-
Hi Drew
Do either of the machines have /etc/libao.conf or ~/.libao/libao.conf present?
-
libao.conf(5) libao configuration libao.conf(5)
NAME
libao.conf - configuration for libao.
SYNOPSIS
/etc/libao.conf
~/.libao
DESCRIPTION
libao.conf and .libao are configuration files for libao, the audio out-
put library. They specify various options to libao, as described
below. libao.conf sets system-wide options, whereas ~/.libao sets
user-specific options. When an option is set in both places, the
option in ~/.libao takes precedence.
FILE FORMAT
The file consists of comments and key-value pairs. Comments are on
separate lines that start with a # symbol. The key-value pairs are of
the form:
key=value
where key contains no whitespace and no equal signs. value will be all
: of the text after the equal sign until (but not including) the ending
newline. Beware of extra spaces at the end of the line! They will
probably be interpreted as part of the option value.
Valid option keys are:
default_driver
The short name of the driver libao should use by default.
Valid values include (not all are available on every
platform): oss, esd, arts, alsa, alsa05, nas, irix, and
sun. Note that "sun" is used on many BSD systems as well
as Solaris. The "alsa" driver is for the 0.9.x ALSA API,
whereas the "alsa05" driver is for the 0.5.x API.
EXAMPLE
Here is an example libao.conf that forces the OSS driver to be used by
default:
# This is a comment.
default_driver=oss
BUGS
libao.conf is missing a number of potentially useful options.
AUTHORS
Stan Seibert <volsung@xiph.org>
September 1, 2003 libao.conf(5)
:
-
Rich,
I ran ls in /etc and found no reference to libao at all.
-
Did you try creating the file as described in the man page above?
-
gerald_clark
No I did not create the file, I simply answered Rich's question. By your post, I assume this needs to be done. Admittedly, I'm having some difficulty trying to figure out what you want me to do first. Do I report the matter to extension authors in reference to ALSA, as I thought I was doing, or do I need to go down a route that I'm totally unfamiliar with? What do we do first?
Further, it isn't abundantly clear to me by the man page just how to create that file. In case you haven't noticed, I am very new to Tinycore, and not at all efficient with this type of manual configuration. Right or wrong, I've been used to other systems doing it for me. Again, nothing good or bad, but it is what it is. I appreciate the time you are spending with this, but it will involve some hand holding. I will do what I can to read documentation first, which I feel I have. After that, who knows?
-
Hi Drew
The first thing I would try is creating an /etc/libao.conf file containing:
default_driver=alsa
-
Okay, did that. Observations: No change to rdesktop yet, still shows libao as driver, also, libao.conf file goes away after reboot.
What else can we do?
-
Well, Core is not a distro per se. It is a tool kit.
I would try the~/.libao/libao.conf first.
If you wish to contact the extension authors, you do it with a private message, not a forum post, but since libao is compiled in, that will probably be the answer.
-
Hi Drew
Gerald_clark beat me to it but Tinycore is not a turnkey system so you need to spend some time reading about how it
works.
... also, libao.conf file goes away after reboot.
Case in point, you haven't even learned about how persistence works, which is very important in this distro. I strongly
recommend you take some time to read this:
http://tinycorelinux.net/book.html
It will serve you well.
-
Note : home should be backed-up when you do a shutdown, so how did /home/tc/.libao/libao.conf disappear?
You did do a backup at shutdown, didn't you?
Did you remove home from .filetool.lst?
-
First of all, I am NOT a TC expert, obviously. And I have read the manual on persistence, I have a .pdf copy of it on my desktop that I have referenced many times since the start of this project.
Secondly, I am not as concerned as to what TC is classified as out of the box -- is it a distro or not? Anyone's guess. You say it's a tool kit -- perfect, we'll go with that. But the shear FACT of the matter is, with just a handful of small extensions, it should accomplish what we need it to, just needs to be ironed out a little for our purpose.
Thirdly, this is what .filetool.lst looks like:
opt
home
opt/eth0.sh
opt/alsa
opt/modprobe.conf
usr/lib/alsa/asound.state
Fourthly, backup is performed on each reboot. Probably won't need to do that every time, but will reduce the frequency of that when we reach a fully working platform that will have no changes made. That was my understanding of persistence. If it is wrong, okay. Then I misunderstood what was well documented in the book, but it wasn't as if it hasn't been consulted. When I installed TC to a flash drive, the only bootcode I used was nodhcp. Everything else was default.
-
Backup is NOT performed on reboot. Restore is.
Backup is done at shutdown if:
1. You use the gui shutdown and have backup selected.
2. At the command line if you run 'filetool.sh -b" or run "backup".
3. You run "exitcheck.sh".
Please post the output of "showbootcodes".
-
The libao extension only seems to include the OSS plugin. So it seems a rebuild of libao.tcz is what's needed, please PM that extension's author.
-
gerald_clark
showbootcodes gives:
initrd=/tce/boot/core/gz quiet nodhcp waitusb=5:UUID="7999f790-92ac-4d8c-8fde-d88dc347281a" tce=UUID="7999f790-92ac-4d8c-8fde-d88dc347281a" BOOT_IMAGE=/tce/boot/vmlinuz
-
That looks good.
-
Perhaps you could try OSS instead of alsa.
-
Interesting you should mention that. I actually installed a set of ALSA plugins from the list of extensions that were shown to include the oss plugin. I'm not exactly sure how to make that plugin operative, or that it would even make a difference.
-
The alsa plugins allow you to run alsa programs on OSS, not the other way around.
I would give OSS a try until such time as libao supports alsa.
Be aware, however, that you cannot load both alsa and OSS. They will conflict.
-
I will try that, thanks. Don't care what or how it works, just need this to work. Will report back with results. May need to do some looking to find out how to get OSS working. Don't know if it's similar to ALSA or not.
-
Remove all alsa extensions from onboot -> reboot -> install OSS.
That's it, if your sound chip is supported, you will now hear some music when you run osstest.
-
It may be that this version was compiled without alsa support.
You need to ask the extension authors.
http://repo.tinycorelinux.net/4.x/x86/tcz/src/rdesktop/rdesktop.build
-
Okay, installed OSS.tcz. Sound test come back good. Still no sound being redirected to client. If I just use '-r sound' in the string, rdesktop reports that "no available sound driver found", just like in the case of ALSA. Perhaps a more complex -r parameter is needed, I've tried many different ones, but they result in other warnings, seg-faults, etc., probably because the string is not quite right. So if it's just the -r variable that is incorrect, then why does "-r sound" work just fine on another work station, with no errors reported after disconnect -- at least none shown in the terminal window? It would seem that there is still something fundamentally missing.
Some of you have suggested that rdesktop is compiled without some critical components. Is now the time to officially discuss that with extension authors?
-
Did you create the libao.conf file for oss as discussed precviously?
-
I tried Rich's suggestion first by creating libao.conf in /etc with code being "default_driver=oss" , not sure if that is even correct. No change.
Please clarify what you mean by trying ~/.libao/libao.conf. Is this a command? If so, I'm getting command not found message.
-
~ is your home directory.
Core is a toolkit, not a install and run distro. You need to have bacic Linux skills.
A good Linux introduction is http://rute.2038bug.com/index.html.gz
-
I will say that I have written, and erased this response many times before actually posting. Admittedly, this is becoming frustrating. Somehow the fact of TC being just a toolkit holds heavy relevance, and when I ask for clarification on specific terminology and how it relates to resolving this issue, I get the response that TC is a toolkit, and I am immediately directed to some additional resource, and that I don't know enough about Linux to use TC, because it's just a toolkit.
Let me explain my application of TC once more. My company has at least 50 thinclient terminals that are still in good working condition that we've had for years. We bought them when thin clients were way less expensive than they are now. We would like to continue using them to connect to newer server technologies -- namely Windows Server 2008r2 and 2012. Toolkit or not, TC loads right up on the thinclients, and works great. The socat extension will allow us to continue using the thinclients as print servers also. The rdesktop extension (an additional tool to add to the kit) plays well with the new server base, which was the biggest bridge to cross. However, it's not perfect, sound being one of it's very few flaws -- at least in this case.
Toolkit or not, I really don't think I need to explain the value of getting this issue resolved. Fifty refreshed thinclients, or 50 new PC's? It is more than a toolkit for us, but you can call it what you want.
Back on topic, this same sound issue with rdesktop was addressed on another thread that is still unsolved. Perhaps I should have gave up then.
-
Hi Drew
Have you tried:
rdesktop -r sound=local
-
Hi Rich,
Yes I have tried entering the parameter that way as well. Once I log off of the server, I see the following message in the terminal window: "WARNING: no working audio driver found"
NOTE: This warning only appears when a sound event is attempted on the server. For example, the process I am running on the server will beep at you if you enter a wrong value, and display an "Item not on file" message. Once I log off of the server after that notification beep is attempted, I get the rdesktop warning noted above. But if no server event normally accompanied by sound takes place, then log-off proceeds with no rdesktop messages displayed in terminal window.
I will also say again, that I'm not entirely convinced that my parameter is somehow incorrect in regard to the -r value. I looked closely at the actual rdesktop help notes that display when you simply run rdesktop. There is a segment about redirecting sound to client, with characters that I'm not familiar with using when setting up and rdesktop connection. This section is also where it mentions the libao driver as being available on TC. On the Ubuntu station, it says ALSA is the available driver. Here is a list of what I've tried so far, probably not all:
-r sound (works fine on Ubuntu station, ALSA is indeed what appears to be the sound driver here)
-r sound:localhost:alsa
-r sound:local:alsa
-r sound:local:libao
-r sound=local (per your suggestion)
-r sound=localhost=alsa
-r sound=localhost=libao
-r sound=local=alsa
-r sound=local=alsa
When I try to use the [,],| characters that are listed in the rdesktop help screen, then I get other seg-fault warnings and errors.
-
I tried Rich's suggestion first by creating libao.conf in /etc with code being "default_driver=oss" , not sure if that is even correct. No change.
As tc extensions should be compiled to /usr/local, this might need to be /usr/local/etc/libao.conf
Please clarify what you mean by trying ~/.libao/libao.conf. Is this a command? If so, I'm getting command not found message.
"~" is shorthand for /home/user, usually /home/tc/.libao/libao.conf
-
Please clarify what you mean by trying ~/.libao/libao.conf.
http://en.wikipedia.org/wiki/Tilde#Directories_and_URLs
-
Hi Juanito
So I created the /usr/local/etc/libao.conf file and since I'm trying OSS, the file says "default_driver=oss". No change, again trying many different -r combinations. I also tried the same approach using ALSA. I haven't found a working configuration yet, so in this case, I simply reboot the .iso, and start over with the extensions just for the current session, so no conflicts are possible between OSS and ALSA on the various attempts.
So my next question is in reference to the /home/tc/.libao/libao.conf. Should the .libao already be in the tc directory? If so, I'm not seeing it. Is this something that needs to be created, and then dropped the libao.conf in that folder?
-
different applications do things in different ways so it's not sure that libao would use /home/tc/.libao/libao.conf, but yes, you might need to create /home/tc/.libao
-
Okay, created /home/tc/.libao/libao.conf containing the line "default=alsa". Still no sound coming to the client. Depending on how I enter the -r parameter, it will still say "no working audio driver found."
In the interim, I've done quite a bit of searching on this matter, more specific to rdesktop, than TC. There is all kinds of suggestions out there like having to also redirect your hard drive to the server, to adding aa_oss at the beginning of the rdesktop string if the alsa-oss wrapper is installed, and so on.
At this point, I've spent so much time on this, that to go in any particular direction seems daunting, not knowing how much time it will take just to find out if it's going to work or not. Then if it doesn't work, going down the other path is that much more daunting. Some part of me thinks that the solution is a very easy one, but just not getting to it yet.
Maybe there are additional steps that I need to take besides creating the /home/tc/.libao/libao.conf.
-
Hi Drew
It's a bit dated, but you could give this a shot:
http://www.xinotes.net/notes/note/891/
-
Hi Rich,
Thanks for the link, but tried that already. Even installed OSS instead of ALSA to give that a spin. And OSS works good with the card, ran osstest, and decent sound resulted.
At this point, I wouldn't be at all surprised if the rdesktop string that I'm using isn't somehow failing to access the sound resource correctly. In looking at the -r help examples, the -r sound parameter appears rather complex. Of course, that would be an rdesktop matter, perhaps I should explore that a little more specifically. If any other suggestions come up, I'd be more than willing to try.
To everybody trying to present a resolution, thanks, I appreciate the effort very much.
-
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.
-
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.
-
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)?
-
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.
-
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.
-
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 \
|' |
-
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.
-
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
-
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...
-
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.
-
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.
-
As said above, before that, libao probably needs to be re-compiled to support alsa
-
Not for me it didnt i only had to recompile rdesktop
-
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.