pdeoliveira wrote: > Hello Ralphy, > First of all, thank you for your great job on SqueezeSlave. > I'm using it on a Linux box with an xmos multichannel reference design > as a USB source. > I'd like to use it for 24/96 files, which is not currently possible. > I've already look into the code, and it seems possible. > I have some programing skills and I'm ready to help. Maybe you already > started some work on this subject and I don't want to make things > twice. > So, please let me know what I can do. > > Pascal The original sources for squeezeslave were hard coded to support 16/44.1 everywhere so it's a major update to the code. All timing and memory allocation calculations assume 16 bits and 44100Hz and the pcm decoder as well. I've managed to add mono support for all the decoders except ogg, but that's really a hack and would likely need to be removed as part of this effort. You'll need to search all the code to find the assumptions. I've tried to add FIXME comments in the code when I've added any such assumptions myself, but Richard didn't always do that.
I think a variable would need to be added to the audio structure to track the sample rate of the current stream. A couple of the decoders don't have a means to obtain the sample rate of the current stream, so that would need to be added. SBS seems to always pass '?' for the sample rate so you can't use that. Ignore the AAC and WMA decoders as I'm planning to rewrite them and they are not part of the official build anyway. The portaudio code expects 44100 as well so there's been no thought in the design on how to change the hardware sample rate if the next track is different from the current one. Also the device list code checks if the device specifically supports 44100. There's also issues with the buffer code that needs to be resolved. I've been working the another forum member to help get squeezeslave ported to the empeg/rio car player. Ideally all buffer code needs to be replaced with some sort of ring buffer implementation. I've looked at using the one included with the port audio svn trunk but it's more work than I'm willing to put into squeezeslave at this time. I think you'll find the buffering code will be the greatest hurdle to overcome and I suspect that increasing both bit size and sampling rate will expose additional issues. The pa_callback is tightly coupled with the buffering code and this will need to be addressed when replacing the buffer engine. There should be no blocking function calls in the callback. However, currently there are three. For the empeg port we've managed to remove two of them, but the last in the slimaudio_buffer_available call can only be removed by changing the buffer code. If you'd like to take a stab at it, I'm happy to help as much as possible with suggestions and testing. A fellow forum member, lauret, has started the work and has provided a patch which partial works. I'd suggest getting in contact with him to obtain the latest version and attempt to co-ordinate you're efforts. I can create a branch on google code for the hi-res project. Here's a quote from lauret regarding the current state lauret wrote: > Well, I have taken a look at the code for a couple of hours, but I > didn't really see a good starting point, so I started with replacing all > the 44.100 and 44100 occurences with resp. 96.000 and 96000 in the > slimaudio dir. With an altered custom-convert.conf (which was already in > place because of 44.1Khz) it worked perfectly! No hiccups or stuttering. > Then I tried the same with 192kHz, and hardcoded it into slimaudio. This > also worked, but it maxed out my server (Atom) with 44.1kHz material. > 96kHz and above worked, I guess that's an easier job for SoX. Still, > 2/3's of my music is in 44.1kHz, the rest is 96kHz or 192kHz, thus this > is for me not an acceptable hack... Also, the bits per sample remain > 16-bits. > > So, next step, how to keep track of the sample rate? I guess in the > slimaudio_t struct? And where is squeezeslave able to detect > sample-rate? In e.g. slimaudio_decoder_flac.c? I haven't heard anything since then and I've made a lot of changes to squeezeslave trunk, which I'll be updating later this week with several more changes. ------------------------------------------------------------------------ ralphy's Profile: http://forums.slimdevices.com/member.php?userid=3484 View this thread: http://forums.slimdevices.com/showthread.php?t=93607 _______________________________________________ discuss mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/discuss
