I recently opened a bug in the RP4MID project about a bluetooth issue that customers are seeing.
https://bugs.helixcommunity.org/show_bug.cgi?id=8405 Since the bug was logged against a private project, then everyone can not see it, but I just added the following comment: <comment> The root cause of the bug is that the bluetooth system does seem to able to deal with sending data that is not alligned with the bits-per-sample. For example, when I play my 32bps clip, helix ends up calling snd_pcm_writei() with a buffer of size 2200 (which translates to a helix buffer of 8800.) If I brute force hack the helix method that sets the audio buffer size (i.e. hxaudses.cpp => CHXAudioSession::CreatePlaybackBuffer()) to 8192 which will result in passing 2048 to snd_pcm_writei(), then the audio distortion goes away. I can also change the ALSA aplay command line utility to use a non aligned value (like 2200 instead of 2048) and witness aplay show the same behavior that this bug documents. I still do not have a patch ready for submission since I need to get a better understand some of the magic in CreatePlaybackBuffer() </comment> This isn't really just a MID device problem, but something that I think anyone using a modern Linux distribution is likely to see. I see it on my Ubuntu Hardy install, and I suspect Fedora 8 users will also see it, which means the many derivative ubuntu/fedora distributions will likely also expose this. Has anyone else stumbled across this yet and have a good idea of how to make helix work around this? I'm still trying to get my head around the audio session code to understand the right way of fixing this. If anyone has some advise on an implementation approach then I would be greatful. --rusty _______________________________________________ Audio-dev mailing list [email protected] http://lists.helixcommunity.org/mailman/listinfo/audio-dev
