Re: [xine-user] Freeze when changing volume. Mutex bug.

[Pierre O. <dr...@dr...>]

On Thu, 2003-08-21 at 19:14, James Courtier-Dutton wrote:
> Pierre Ossman wrote:
> > I've tracked down a pretty serious sync. bug in the audio system.
> > 
> > The problem manifests itself as a freeze of the user interface when
> > changing the volume (including muting). I searched around and realized I
> > wasn't the only one who had run in to this. No one seemed to have found
> > either the cause or a solution to it however.
> > I have (partially) solved both ;)
> > 
> > The cause of it all is the mutex handling access to the audio driver.
> > Writing of new data to the sound card however keeps this mutex locked more
> > or less indefinetly (sp?). From the code it seems this shouldn't happen
> > (since the writing routine locks the mutex, writes the data and then
> > unlocks it again). But from my experience with multi-threaded programming
> > I'm guessing that the audio thread has time to do another loop during its
> > time slice and ends up inside the lock again. The solution, of course, is
> > to make sure that the system switches thread outside the lock. To do this
> > I've successfully tested adding a usleep(1) after the mutex is unlocked.
> > This should put the writing thread in a sleeping state and the scheduler
> > should take care of the volume changing thread instead. I'm not 100%
> > familiar with the process schedulers on all supported systems but this
> > should work on any platform.
> > 
> > I might have gone overboard with the description here but I figured you
> > guys wouldn't want to include changes you don't fully understand.
> > 
> > In short. To solve the problem add a:
> > 
> > usleep(1);
> > 
> > after:
> > 
> > pthread_mutex_lock( &this->driver_lock );
> > result = this->driver->write (this->driver, out_buf->mem,
> > ut_buf->num_frames );
> > pthread_mutex_unlock( &this->driver_lock );
> > 
> > in ao_loop in src/xine-engine/audio_out.c of xine-lib
> > 
> > If you have any questions please cc them to my email aswell since I'm not
> > following this mailing too much...
> > 
> > It would be nice if this made it into the next release. If not then you
> > might need to add something in the FAQ about it. I was ready to give up on
> > xine for a while and it seems the other people who have encountered this
> > bug have done just that.
> > 
> > Rgds Pierre Ossman
> > 
> Can you supply details of which sound card you are using, and which 
> drivers your are using for that sound card.
> The problem has been known about for a long time.
> I solution we came to was to use one lock for audio out, and another 
> lock for any mixer access, so that they would never block each other.
> I believe the initial reason for the lock in the first place was just 
> buggy oss drivers.
> Cheers
> James
> 
> 

I'm using a Sound Blaster Live Value with the kernel (2.4.20) OSS driver
emu10k1 version 0.20.
Is there some other work-around for this? I don't want to keep running a
home-patched version unless I have to.

Rgds Pierre