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
[email protected]
http://lists.helixcommunity.org/mailman/listinfo/audio-dev
_______________________________________________
Audio-dev mailing list
[email protected]
http://lists.helixcommunity.org/mailman/listinfo/audio-dev
