Re: Audio sink stream remains suspended on reconnection

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Alex,

On Sat, May 11, 2013 at 4:51 AM, Alex Deymo <deymo@xxxxxxxxxxxx> wrote:
> Hi Luiz,
>
> On Fri, May 10, 2013 at 1:09 AM, Luiz Augusto von Dentz
> <luiz.dentz@xxxxxxxxx> wrote:
>> Yes, you should release the fd once the state change to idle, in the
>> future we might actually use frevoke (http://lwn.net/Articles/192632/)
>> to revoke the permissions but for now we have to assume the endpoint
>> will behave and close whenever the transport became idle. You are also
>> right, we should probably update the documentation to state the fd is
>> considered revoked in this case and the endpoint has to acquired
>> again. Btw PulseAudio does that already so Im curious why you are not
>> using PA, or is this for another Audio daemon?
>
> Oh, thank you very much for that information. I would never guessed
> that was the problem!
> Having the documentation clear and updated is good not only because
> not everyone uses PA, but also because definitively we don't want to
> use PA for testing (we may want to fake and control the interaction
> with the audio server to run a test). Actually, as Scott mentioned we
> are not using PA on Chromium/ChromiumOS laptops, we are using CRAS
> (ChromeOS Audio Server) which is basically the minimum we need to have
> low latency dynamic audio routing with a low CPU impact... and that's
> basically the "why". If you are curious, you can find the original
> design doc here [1], the code is opensource and here [2] and actually
> also works on ubuntu [3], but need applications (like chrome) that
> know how to talk with cras.

If you fill that you can put some effort in improving the
documentation patches are welcome, I hope now it is clear how the
state should handled, you can still overwrite and request to resume by
doing Acquire but the remote stack may refuse to do so, it is actually
recommended that whoever suspend should resume.

Regarding PulseAudio, it is a bit frustrating to see very little
effort for adapting PA for whatever you guys need and btw Arun did
ported PA to Android and compared it with AudioFlinger:

http://arunraghavan.net/2012/01/pulseaudio-vs-audioflinger-fight/

It doesn't look like PA is power hog, it can get low latency as well,
anyway it is probably not a good idea to talk about this in
linux-bluetooth, there are very competent guys in PA mailing list to
discuss about this.
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux