Daniel Yek wrote:
For trouble-shooting purposes, put the following line anywhere -- an
independent line:
defaults.pcm.subdevice -1
Without this line, you default subdevice might not be set properly.
*Maybe* what would then happen is that subdevice gets set to 0 and
EBUSY could then happen. If subdevice is -1, EBUSY should not happen
(from what I can tell, that is.)
It is possible that you can enter this following line inside the
pcm.snd_card block above:
subdevice -1
If these don't fix the EBUSY problem, you should check out
/etc/alsa/alsa.conf for subdevice not equal to -1.
After that, check:
/etc/alsa/cards/yourAlsaDriverName.conf
Then, email [email protected] might be more helpful.
Daniel -
Just wanted to let you know that I tried all of the above and no dice.
The EBUSY is being returned from the driver, not the alsa-lib, so it
looks like sub-devices are not involved.
One of the things I did discover is that we're running an older version
of the alsa-driver ( 1.0.9rc2 ) that came with our kernel. This means
we're also running a mis-matched version of alsa-lib ( 1.0.11rc4 ).
So, I'm in the middle of porting our changes to our low-level driver (
cs5535_audio ) to the latest version of the stable version of the
alsa-driver ( 1.0.13 ) in hopes that the bug may have been fixed
already. This also will allow us to run the latest driver and lib
versions together.
Thanks again for your help!
We might need to improve Helix's audio code too, especially if your
EBUSY problem isn't worked around.
I think there's still definately a bug that causes a crash when EBUSY is
returned on the open. If you want, I can file a bug when I get back
from the Holidays...
Happy Holidays & New Years!
Tony Espy
Pepper Computer
Thanks.
_______________________________________________
Audio-dev mailing list
[email protected]
http://lists.helixcommunity.org/mailman/listinfo/audio-dev
