Re: [Bluez-devel] An explanation of a2dpd weird behaviour on high resolution timers enabled kernels

[Marcel Holtmann <marcel@holtmann.org>]

Hi Fabien,

> >> Ok, then we have to implement snd_pcm_get_delay() and offer the option 
> >> to the application to sleep itself (or do other time consuming tasks 
> >> such as video decoding). However when the application sends data too 
> >> fast (such as a simple aplay) we *have* to do the sleeping ourselves to 
> >> prevents cuts on the headset side :-)
> > 
> > Aplay is not sending the data too fast. aplay tries to fill the sound
> > card buffer as 100% of sound playing application do.
> > Buffer size being known, delay determine available space. When there is
> > space, aplay writes data and that's all.
> > 
> > The current plugin delay implementation is the number of data written
> > (not played) => delay is always 0 => buffer is always empty => aplay
> > fills it => plugin have to wait in the write() call.
> > 
> 
> Ok, this time i understood. I agree with you. Which means two things:
>   * i basically screwed up the pcm plugin i did a while ago for headsetd 
> :-(. I was wrongs about the sleeping stuff. I understood alsa dynamic 
> behaviour the wrong way.
>   * ALSA API has the builtin assomption that the data gets transmitted 
> using a hardware ring buffer, which is not the bluetooth way of things 
> when you send packets one after the other.
> 
> This means we have to workaround this by implementing a virtual buffer 
> with a virtual hardware pointer.
> While as Marcel, i'm not a big fan of threads, i'd tend to see them here 
> as the less worse alternative we have :-) : so i'd say : let's go with 
> threads !!

just a small correction. I hate threads. However since ALSA already uses
them, we can do, too. Otherwise you would never convince me to use
threads.

> > In fact, the only application to care about is the sound server.
> 
> Could you be more specific on that ?
> If you think of pulseaudio as the sound server, i'm afraid a native 
> pulse plugin will have to be written for good bluetooth support anyway.

That is the plan in the end. Having a native PulseAudio plugin that
connects over our IPC to the audio service.

Regards

Marcel



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel