Re: [Gap-dev-discuss] Cynthiune : add an alsa backend for linux

[Philippe Roussel]

Hi Sebastian, and thanks for testing.

Le 03/05/2012 18:32, Sebastian Reitenbach a écrit :
> 
> I tested on OpenBSD, and it generally works. But it seems, you are facing 
> exactly the same problem
> like I do. I tested playing FLAC and MP3 files, works well. But I have one 
> FLAC file in my playlist
> which has a bit rate of 16000Hz, all the other MP3 files have 44100Hz.
> 
> When the sound output is stopped, and I just double click the FLAC file or 
> any MP3, it starts 
> playing that file, with the right bit rate. 
> But when the playlist is playing, and it jumps from a 44100Hz MP3 to the 
> 16000 FLAC file, 
> then the FLAC file is played too fast. When I start playing music by double 
> clicking the 16000Hz
> FLAC file, and it then jumps to the 44100Hz MP3, the MP3 is played too slow.
> I added a NSLog in the metthod like this:
> 
> - (BOOL) prepareDeviceWithChannels: (unsigned int) numberOfChannels
>                            andRate: (unsigned long) sampleRate
> {
> NSLog(@"prepareDevice: Channels: %u rate: %lu", numberOfChannels, sampleRate);
>   format.channels = (int)numberOfChannels;
>   format.rate = (int)sampleRate;
> ...
> 
> 
> and on the console, I see, when it automatically jumps to the next song, the 
> method is called
> with the right bit rate, but the rate is not changed correctly while the play 
> thread is still running. 
> 
> I thought about using a lock, so that in the playing thread, so the 
> prepareDeviceWithChannels
> creates a lock to pause the playing thread. Then when this thread is paused 
> playing, it makes the
> changes to the bit rate, and maybe channels, and then the lock will be opened 
> again, and 
> then the play thread will start playing again. But I haven't yet figured out, 
> how to get that right,
> since I still run into race conditions between the threads.
> 
> The test FLAC file I use can be found here.
> http://code.google.com/p/cs-4244-mkl/source/browse/trunk/project-4/GSTT/mike-test.flac?r=202

I'll try to reproduce this tonight and hopefully fix the problem.

We may have other problems like this with files not using 16 bits per
sample, I guess you was the FIXME in the code. We would have to get this
information from the song but in the backend we only have access to raw
data.

Anyway, I'll let you know if I find something.

Philippe