150Cay: Crash in CAudioOutUNIX

I just discovered a crash in CAudioOutUNIX::_Imp_Pause() on
the 150Cay 
branch during local MP3 playback.

The crash occurred on a Pepper Pad3 ( AMD Geode, Linux
2.6.13 ).  We use 
the Helix client engine driven by a Java JNI library written
here at Pepper.

Our preferences file has the following settings for ALSA:

sounddriver=3
alsavaryingsamplerate=1

Before playback of a song begins the
CHXAudioSession::Setup() calls 
::GetDeviceFormat(), which eventually results in the 
CHXAudioDevice::CheckFormat() being called.  This call then
results in a 
call to the low level platform-specific _CheckFormat() being
called.

In the underlying ALSA audio device impl, it's possible for
the call to 
snd_pcm_open() in ::_OpenAudio() to fail with an EBUSY error
code.  If 
this happens, the HXAudioFormat is left unitialized, but the
playback 
sequence continues.

This eventually results in a crash in the function 
CAudioOutUNIX::_Imp_Pause().  It fails with a SIGFPE due to
the 
following line of code:

//Make sure we only deal with full samples.
Bytes-per-sample*num-channels.
         int nRem =
ulNumBytesToRewind%(m_uSampFrameSize*m_unNumChannels);

In this case 'm_uSampFrameSize' = 0.  This variable is
initialized using 
the from the HXAudioFormat instance:

m_uSampFrameSize = pFormat->uBitsPerSample / 8;

In this case, due to the above EBUSY returned in the
_OpenAudio() 
function, uBitsPerSample is 0.

I'm not sure how to fix this problem.  I'm going to try a
retry loop in 
_OpenAudio(), but I'm not sure that's the correct fix.

Thanks,
Tony Espy
Pepper Computer


_______________________________________________
Audio-dev mailing list
Audio-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/audio
-dev

Hi Tony,

Thanks so much for the detailed report. It helped
enormously.


At 02:09 PM 12/13/2006, Tony Espy wrote:
>I just discovered a crash in CAudioOutUNIX::_Imp_Pause()
on the 150Cay 
>branch during local MP3 playback.
>
>The crash occurred on a Pepper Pad3 ( AMD Geode, Linux
2.6.13 ).  We use 
>the Helix client engine driven by a Java JNI library
written here at Pepper.
>
>Our preferences file has the following settings for
ALSA:
>
>sounddriver=3
>alsavaryingsamplerate=1
>
>Before playback of a song begins the
CHXAudioSession::Setup() calls 
>::GetDeviceFormat(), which eventually results in the 
>CHXAudioDevice::CheckFormat() being called.  This call
then results in a 
>call to the low level platform-specific _CheckFormat()
being called.
>
>In the underlying ALSA audio device impl, it's possible
for the call to 
>snd_pcm_open() in ::_OpenAudio() to fail with an EBUSY
error code.

Could you try out the following patch? There is a success
path through 
CAudioOutLinuxAlsa:_OpenAudio() where wLastError was not set
to RA_AOE_NOERR.

Index: audlinux_alsa.cpp
============================================================
=======
RCS file:
/cvsroot/audio/device/platform/unix/audlinux_alsa.cpp,v
retrieving revision 1.4.6.4
diff -u -w -r1.4.6.4 audlinux_alsa.cpp
--- audlinux_alsa.cpp   26 Oct 2006 22:33:01 -0000     
1.4.6.4
+++ audlinux_alsa.cpp   14 Dec 2006 01:35:47 -0000
 -155,7
+155,7 
  {
      int err = 0;
      const char* szDevice;
-    HX_RESULT wLastError;
+    HX_RESULT wLastError = RA_AOE_NOERR;

      HXLOGL4 (HXLOG_ADEV, "_OpenAudio() %s",
m_bCheckFormat? "while 
checking format!" : "outside
_CheckFormat()!");




>If this happens, the HXAudioFormat is left unitialized,
but the playback 
>sequence continues.

I think it is not a problem with HXAudioFormat not being
initialized. (It 
is a const input parameter...)



>This eventually results in a crash in the function 
>CAudioOutUNIX::_Imp_Pause().  It fails with a SIGFPE due
to the following 
>line of code:
>
>//Make sure we only deal with full samples.
>Bytes-per-sample*num-channels.
>         int nRem =
ulNumBytesToRewind%(m_uSampFrameSize*m_unNumChannels);

This only happens when:
Supports HW Pause: 0

I suppose you saw this output if the audio device is opened
successfully. 
Just to verify...

>In this case 'm_uSampFrameSize' = 0.  This variable is
initialized using 
>the from the HXAudioFormat instance:
>
>m_uSampFrameSize = pFormat->uBitsPerSample / 8;

m_uSampFrameSize is only set up in
CAudioOutLinuxAlsa::_SetDeviceConfig(), 
which is called when the device was opened successfully.


I'm puzzling over where CAudioOutUNIX::_Imp_Pause() being
called when 
device open wasn't successful (or at least, was reported to
be not 
successful, while in fact, it was successful.)

Is there such a condition? We would have to look there to
see if it needs 
fixing.


>In this case, due to the above EBUSY returned in the
_OpenAudio() 
>function, uBitsPerSample is 0.

I'm suspecting that _OpenAudio() returned an un-initialized
value in one 
path through the function.

Thanks, Tony. Let me know if that patch works. My sound card
has hardware 
pause support, so I can't repro. this problem.


>I'm not sure how to fix this problem.  I'm going to try
a retry loop in 
>_OpenAudio(), but I'm not sure that's the correct fix.
>
>Thanks,
>Tony Espy
>Pepper Computer




-- 
Daniel Yek


_______________________________________________
Audio-dev mailing list
Audio-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/audio
-dev

Daniel Yek wrote:
> Thanks so much for the detailed report. It helped
enormously.

no problem.  the more details i supply, the better chance
y'all will be 
able to help me fix the problem!


> Could you try out the following patch? There is a
success path through 
> CAudioOutLinuxAlsa:_OpenAudio() where wLastError was
not set to 
> RA_AOE_NOERR.
> 
> Index: audlinux_alsa.cpp
>
============================================================
=======
> RCS file:
/cvsroot/audio/device/platform/unix/audlinux_alsa.cpp,v
> retrieving revision 1.4.6.4
> diff -u -w -r1.4.6.4 audlinux_alsa.cpp
> --- audlinux_alsa.cpp   26 Oct 2006 22:33:01 -0000     
1.4.6.4
> +++ audlinux_alsa.cpp   14 Dec 2006 01:35:47 -0000
>  -155,7 +155,7 
>  {
>      int err = 0;
>      const char* szDevice;
> -    HX_RESULT wLastError;
> +    HX_RESULT wLastError = RA_AOE_NOERR;

nope, didn't fix it.

>> This eventually results in a crash in the function 
>> CAudioOutUNIX::_Imp_Pause().  It fails with a
SIGFPE due to the 
>> following line of code:
>>
>> //Make sure we only deal with full samples.
>> Bytes-per-sample*num-channels.
>>         int nRem =
ulNumBytesToRewind%(m_uSampFrameSize*m_unNumChannels);
> 
> This only happens when:
> Supports HW Pause: 0
>
> I suppose you saw this output if the audio device is
opened 
> successfully. Just to verify...

yes, i did see this output.  no hardware pause support.  ;(-

> I'm puzzling over where CAudioOutUNIX::_Imp_Pause()
being called when 
> device open wasn't successful (or at least, was
reported to be not 
> successful, while in fact, it was successful.)
> 
> Is there such a condition? We would have to look there
to see if it 
> needs fixing.

yea, there does seem to be such a condition...


>> In this case, due to the above EBUSY returned in
the _OpenAudio() 
>> function, uBitsPerSample is 0.
> 
> I'm suspecting that _OpenAudio() returned an
un-initialized value in one 
> path through the function.
> 
> Thanks, Tony. Let me know if that patch works. My sound
card has 
> hardware pause support, so I can't repro. this problem.

an easy way to reproduce the problem is in _OpenAudio(), set
err = 
-EBUSY right after the call to snd_pcm_open().

when i do this, i hit the problem every time.

/t

_______________________________________________
Audio-dev mailing list
Audio-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/audio
-dev

danial -

some more info...

when things work correctly, i see the following log messages
( some 
added by me ):

CHXAudioSession[0x8a36210]::GetDeviceFormat()
CHXAudioSession[0x8a36210]::GetDeviceFormat() samp: 44100
ch: 2 bits: 16
_OpenAudio() while checking format!
Opening ALSA PCM device, default, to check format!
_OpenAudio() open OK
Closing ALSA PCM device after check format!

when things fail, I see:

CHXAudioSession[0x8a36210]::GetDeviceFormat()
CHXAudioSession[0x8a36210]::GetDeviceFormat() samp: 44100
ch: 2 bits: 16
_OpenAudio() while checking format!
Opening ALSA PCM device, default, to check format!
snd_pcm_open: default Device or resource busy
CHXAudioSession[0x8a36210]::CheckFormat() returning
HXR_AUDIO_DRIVER!!!
CHXAudioSession[0x8a36210]::GetDeviceFormat() samp: 44100
ch: 2 bits: 16
_OpenAudio() while checking format!
Opening ALSA PCM device, default, to check format!
snd_pcm_open: default Device or resource busy
CHXAudioSession[0x8a36210]::CheckFormat() returning
HXR_AUDIO_DRIVER!!!
CHXAudioSession[0x8a36210]::GetDeviceFormat() samp: 44100
ch: 1 bits: 16
_OpenAudio() while checking format!
Opening ALSA PCM device, default, to check format!
snd_pcm_open: default Device or resource busy
CHXAudioSession[0x8a36210]::CheckFormat() returning
HXR_AUDIO_DRIVER!!!
CHXAudioSession[0x8a36210]::GetDeviceFormat() samp: 44100
ch: 2 bits: 8
_OpenAudio() while checking format!
Opening ALSA PCM device, default, to check format!
snd_pcm_open: default Device or resource busy
CHXAudioSession[0x8a36210]::CheckFormat() returning
HXR_AUDIO_DRIVER!!!
CHXAudioSession[0x8a36210]::GetDeviceFormat() samp: 44100
ch: 1 bits: 8
.
.
.

CHXAudioSession[0x8a36210]::GetDeviceFormat() samp: 8000 ch:
1 bits: 8
_OpenAudio() while checking format!
Opening ALSA PCM device, default, to check format!
snd_pcm_open: default Device or resource busy
CHXAudioSession[0x8a36210]::CheckFormat() returning
HXR_AUDIO_DRIVER!!!
CHXAudioSession[0x8a36210]::GetDeviceFormat() theErr set...
_Imp_Pause() sample frame size: 0 num channels: 1

KA-BOOM.

One problem I see is that CAudioOutLinuxALSA::_OpenAudio()
doesn't treat 
an EBUSY returned by snd_pcm_open() any differently than
other open errors.

This causes the CHXAudioSession::CheckFormat() code to
repeatedly call 
pDevice->CheckFormat() over and over again cause it's
trying to find a 
valid output format.  It seems to me that if ALSA is
reporting EBUSY, 
that repeatedly trying open it without giving things time to
settle down 
is a bad idea...

I'm still not sure why the driver is reporting EBUSY, but I
would think 
that you'd want to wait a few before attempting another open
call.

Anyways, that's it for me tonite...

Thanks Again,
Tony Espy
Pepper Computer






_______________________________________________
Audio-dev mailing list
Audio-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/audio
-dev

one more puzzling question...

if i'm reading the code in CAudioOutLinuxAlsa::_OpenAudio()
correctly, 
the call to snd_pcm_open() is made in blocking mode,
correct?

err = snd_pcm_open( &m_pAlsaPCMHandle,
                     szDevice,
                     SND_PCM_STREAM_PLAYBACK,
                     0);

here's the definition of the NONBLOCK flag in pcm.h:

#define SND_PCM_NONBLOCK                0x0001

if this is true, how come EBUSY can still be returned???

also, the code the explicitly sets the mode to nonblock via
this call:

err = snd_pcm_nonblock(m_pAlsaPCMHandle, FALSE);

again, if the open was made in blocking mode, why does it
need to be set 
again?

thanks,
/tony





_______________________________________________
Audio-dev mailing list
Audio-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/audio
-dev

Tony Espy wrote:
> I just discovered a crash in
CAudioOutUNIX::_Imp_Pause() on the 150Cay 
> branch during local MP3 playback.
> 
> The crash occurred on a Pepper Pad3 ( AMD Geode, Linux
2.6.13 ).  We use 
> the Helix client engine driven by a Java JNI library
written here at 
> Pepper.
> 
> Our preferences file has the following settings for
ALSA:
> 
> sounddriver=3
> alsavaryingsamplerate=1
> 
> Before playback of a song begins the
CHXAudioSession::Setup() calls 
> ::GetDeviceFormat(), which eventually results in the 
> CHXAudioDevice::CheckFormat() being called.  This call
then results in a 
> call to the low level platform-specific _CheckFormat()
being called.
> 
> In the underlying ALSA audio device impl, it's possible
for the call to 
> snd_pcm_open() in ::_OpenAudio() to fail with an EBUSY
error code.  If 
> this happens, the HXAudioFormat is left unitialized,
but the playback 
> sequence continues.

I think this is the real problem. It looks like in the
client/audiosvc code
we treat both HXR_OK and certain HXR error codes as OK. I
see that in
different parts of the code we do stuff like:

if (!theErr || theErr == HXR_AUDIO_DRIVER)
     {
         m_ActualDeviceFmt = m_DeviceFmt;
     .....

and

    retCode = _CheckFormat( pFormat );
     if( RA_AOE_NOERR != retCode && RA_AOE_DEVBUSY
!= retCode )
     {
         m_wLastError = HXR_FAILED;
     }
     else
     {
         m_wLastError = HXR_OK;
     }


If the device was busy it looks like we just hope it isn't
busy by the time we go to playback content. This also means
that we would have looped through out whole table of
preferred
audio formats and defaulted to the least desirable one (the
last one in the table).

One way to *PERHAPS* fix this, since you are on a physical
device where you will know the capabilities of your sound
card, is to hard code the checkformat calls. That is, don't
open the device to check formats. You know what the card
can do, so just return true or false depending on a hard
coded list. Even if the pepper's do change sound devices,
this might be a good test to see if that is the real
problem.

If the device is still busy when we go to open the audio
for playback, hopefully we will just fail to open and not
continue.

Can you try something like that and see what happens?
--greg.


> 
> This eventually results in a crash in the function 
> CAudioOutUNIX::_Imp_Pause().  It fails with a SIGFPE
due to the 
> following line of code:
> 
> //Make sure we only deal with full samples.
> Bytes-per-sample*num-channels.
>         int nRem =
ulNumBytesToRewind%(m_uSampFrameSize*m_unNumChannels);
> 
> In this case 'm_uSampFrameSize' = 0.  This variable is
initialized using 
> the from the HXAudioFormat instance:
> 
> m_uSampFrameSize = pFormat->uBitsPerSample / 8;
> 
> In this case, due to the above EBUSY returned in the
_OpenAudio() 
> function, uBitsPerSample is 0.
> 
> I'm not sure how to fix this problem.  I'm going to try
a retry loop in 
> _OpenAudio(), but I'm not sure that's the correct fix.
> 
> Thanks,
> Tony Espy
> Pepper Computer
> 
> 
> _______________________________________________
> Audio-dev mailing list
> Audio-devhelixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/audio
-dev


_______________________________________________
Audio-dev mailing list
Audio-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/audio
-dev

Thanks for pointing out the problems area, Greg.

Tony: Comment inline.

At 10:54 AM 12/14/2006, Greg Wright wrote:
>Tony Espy wrote:
>>I just discovered a crash in
CAudioOutUNIX::_Imp_Pause() on the 150Cay 
>>branch during local MP3 playback.
>>The crash occurred on a Pepper Pad3 ( AMD Geode,
Linux 2.6.13 ).  We use 
>>the Helix client engine driven by a Java JNI library
written here at Pepper.
>>Our preferences file has the following settings for
ALSA:
>>sounddriver=3
>>alsavaryingsamplerate=1
>>Before playback of a song begins the
CHXAudioSession::Setup() calls 
>>::GetDeviceFormat(), which eventually results in the

>>CHXAudioDevice::CheckFormat() being called.  This
call then results in a 
>>call to the low level platform-specific
_CheckFormat() being called.
>>In the underlying ALSA audio device impl, it's
possible for the call to 
>>snd_pcm_open() in ::_OpenAudio() to fail with an
EBUSY error code.  If 
>>this happens, the HXAudioFormat is left unitialized,
but the playback 
>>sequence continues.

I believe you would only get EBUSY if your ALSA
configuration specifies a 
subdevice. If the subdevice is unavailable (used by other
application, for 
example, and you are using dmix), EBUSY would be returned,
instead of using 
the next available subdevice.

Could you check if there is such a place where a subdevice
is specified and 
if removing it or set it to -1 (default) resolves your
problem?


-- 
Daniel Yek




>I think this is the real problem. It looks like in the
client/audiosvc code
>we treat both HXR_OK and certain HXR error codes as OK.
I see that in
>different parts of the code we do stuff like:
>
>if (!theErr || theErr == HXR_AUDIO_DRIVER)
>     {
>         m_ActualDeviceFmt = m_DeviceFmt;
>     .....
>
>and
>
>    retCode = _CheckFormat( pFormat );
>     if( RA_AOE_NOERR != retCode &&
RA_AOE_DEVBUSY != retCode )
>     {
>         m_wLastError = HXR_FAILED;
>     }
>     else
>     {
>         m_wLastError = HXR_OK;
>     }
>
>
>If the device was busy it looks like we just hope it
isn't
>busy by the time we go to playback content. This also
means
>that we would have looped through out whole table of
preferred
>audio formats and defaulted to the least desirable one
(the
>last one in the table).
>
>One way to *PERHAPS* fix this, since you are on a
physical
>device where you will know the capabilities of your
sound
>card, is to hard code the checkformat calls. That is,
don't
>open the device to check formats. You know what the card
>can do, so just return true or false depending on a hard
>coded list. Even if the pepper's do change sound
devices,
>this might be a good test to see if that is the real
problem.
>
>If the device is still busy when we go to open the audio
>for playback, hopefully we will just fail to open and
not
>continue.
>
>Can you try something like that and see what happens?
>--greg.
>
>
>>This eventually results in a crash in the function 
>>CAudioOutUNIX::_Imp_Pause().  It fails with a SIGFPE
due to the following 
>>line of code:
>>//Make sure we only deal with full samples.
>>Bytes-per-sample*num-channels.
>>         int nRem =
ulNumBytesToRewind%(m_uSampFrameSize*m_unNumChannels);
>>In this case 'm_uSampFrameSize' = 0.  This variable
is initialized using 
>>the from the HXAudioFormat instance:
>>m_uSampFrameSize = pFormat->uBitsPerSample / 8;
>>In this case, due to the above EBUSY returned in the
_OpenAudio() 
>>function, uBitsPerSample is 0.
>>I'm not sure how to fix this problem.  I'm going to
try a retry loop in 
>>_OpenAudio(), but I'm not sure that's the correct
fix.
>>Thanks,
>>Tony Espy
>>Pepper Computer


_______________________________________________
Audio-dev mailing list
Audio-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/audio
-dev

Daniel Yek wrote:
>>> In the underlying ALSA audio device impl, it's
possible for the call 
>>> to snd_pcm_open() in ::_OpenAudio() to fail
with an EBUSY error 
>>> code.  If this happens, the HXAudioFormat is
left unitialized, but 
>>> the playback sequence continues.
> 
> I believe you would only get EBUSY if your ALSA
configuration specifies 
> a subdevice. If the subdevice is unavailable (used by
other application, 
> for example, and you are using dmix), EBUSY would be
returned, instead 
> of using the next available subdevice.
> 
> Could you check if there is such a place where a
subdevice is specified 
> and if removing it or set it to -1 (default) resolves
your problem?

We're using dmix, and we also have alsa-oss installed (
1.0.11rc3 ). 
Our version of alsa-lib is 1.0.11rc4.

Our asound.conf is setup with a duplex device for mic input,
however 
even after removing it, the problem still occurs.

we do have a couple of devices defined for our alsa-oss
library.  do 
these cause sub-devices to be configured???

thanks again for all your help!

/tony

Here's my stripped down version of asound.conf:

pcm.snd_card {
      type hw
      card 0
}

# Allow mixing of multiple output streams to this device
pcm.dmixer {
      type dmix
      ipc_key 1024
      slave.pcm "snd_card"
      slave {
           # This stuff provides some fixes for latency
issues.
           # buffer_size should be set for your audio
chipset.
           period_time 0
           period_size 1024
           buffer_size 32768
      }

      bindings {
           0 0
           1 1
      }
}

###################
# CONVERSION PLUG #
###################
# Setting the default pcm device allows the conversion
# rate to be selected on the fly.
# duplex mode allows any alsa enabled app to read/write
# to the dmix plug (Fixes a problem with wine).

pcm.!default {
      type plug
      slave.pcm "dmixer"
}

########
# AOSS #
########
# OSS dsp0 device (OSS needs only output support, duplex
will break some 
stuff)
pcm.dsp0 {
      type plug
      slave.pcm "dmixer"
}

# OSS control for dsp0 (needed?...this might not be useful)
ctl.dsp0 {
      type plug
      slave.pcm "snd_card"
}

# OSS control for dsp0 (default old OSS is mixer0)
ctl.mixer0 {
      type plug
      slave.pcm "snd_card"
}

_______________________________________________
Audio-dev mailing list
Audio-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/audio
-dev

Hi Tony,

At 02:26 PM 12/14/2006, Tony Espy wrote:
>Daniel Yek wrote:
>>>>In the underlying ALSA audio device impl,
it's possible for the call to 
>>>>snd_pcm_open() in ::_OpenAudio() to fail
with an EBUSY error code.  If 
>>>>this happens, the HXAudioFormat is left
unitialized, but the playback 
>>>>sequence continues.
>>I believe you would only get EBUSY if your ALSA
configuration specifies a 
>>subdevice. If the subdevice is unavailable (used by
other application, 
>>for example, and you are using dmix), EBUSY would be
returned, instead of 
>>using the next available subdevice.
>>Could you check if there is such a place where a
subdevice is specified 
>>and if removing it or set it to -1 (default)
resolves your problem?
>
>We're using dmix, and we also have alsa-oss installed (
1.0.11rc3 ). Our 
>version of alsa-lib is 1.0.11rc4.
>
>Our asound.conf is setup with a duplex device for mic
input, however even 
>after removing it, the problem still occurs.
>
>we do have a couple of devices defined for our alsa-oss
library.  do these 
>cause sub-devices to be configured???
>
>thanks again for all your help!
>
>/tony
>
>Here's my stripped down version of asound.conf:
>
>pcm.snd_card {
>      type hw
>      card 0

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 alsa-devellists.sourceforge.net might be more
helpful.

We might need to improve Helix's audio code too, especially
if your EBUSY 
problem isn't worked around.

Thanks.


-- 
Daniel Yek


>}
>
># Allow mixing of multiple output streams to this device
>pcm.dmixer {
>      type dmix
>      ipc_key 1024
>      slave.pcm "snd_card"
>      slave {
>           # This stuff provides some fixes for latency
issues.
>           # buffer_size should be set for your audio
chipset.
>           period_time 0
>           period_size 1024
>           buffer_size 32768
>      }
>
>      bindings {
>           0 0
>           1 1
>      }
>}
>
>###################
># CONVERSION PLUG #
>###################
># Setting the default pcm device allows the conversion
># rate to be selected on the fly.
># duplex mode allows any alsa enabled app to read/write
># to the dmix plug (Fixes a problem with wine).
>
>pcm.!default {
>      type plug
>      slave.pcm "dmixer"
>}
>
>########
># AOSS #
>########
># OSS dsp0 device (OSS needs only output support, duplex
will break some 
>stuff)
>pcm.dsp0 {
>      type plug
>      slave.pcm "dmixer"
>}
>
># OSS control for dsp0 (needed?...this might not be
useful)
>ctl.dsp0 {
>      type plug
>      slave.pcm "snd_card"
>}
>
># OSS control for dsp0 (default old OSS is mixer0)
>ctl.mixer0 {
>      type plug
>      slave.pcm "snd_card"
>}


_______________________________________________
Audio-dev mailing list
Audio-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/audio
-dev

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 alsa-devellists.sourceforge.net 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
Audio-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/audio
-dev