Hello all
I'm developing an application that records all kinds of audio using GStreamer.
Target platform is the Nokia N900, the app is called Recaller
(http://maemo.org/downloads/product/Maemo5/recaller/)
All works well except when ending the recording of Bluetooth
Conversations: Once a party hangs up the call, the PulseAudio source
and sink disappear before I can stop GStreamer recording (I'm
listening to D-Bus events). Unfortunately, this causes my GStreamer
pipeline to crash.
Is there a way to either delay the destruction of the sink/source by
Bluez or a D-Bus message I could intercept/attach to? How can I "win
the race"?
Thank you for your support and hints (and for the outstanding work you
all do on Bluez - a fascinating part of the Linux ecosystem!)
-Tom
Hi,
On Fri, Oct 29, 2010 at 7:19 PM, Peter Dons Tychsen <[email protected]> wrote:
> On Wed, 2010-10-27 at 22:03 +0200, Thomas W?lti wrote:
>
>> All works well except when ending the recording of Bluetooth
>> Conversations: Once a party hangs up the call, the PulseAudio source
>> and sink disappear before I can stop GStreamer recording (I'm
>> listening to D-Bus events). Unfortunately, this causes my GStreamer
>> pipeline to crash.
Well then there is a problem in your pipeline, bluetooth sinks and
sources may disappear at any point and in fact PA do move audio,
depending on the system policy, when that occurs. Also note that
bluetooth modules do handle DisconnectRequest signal so it might react
a bit faster when user request audio to be disconnected, but that
should not make any difference for an application using PA.
> There are many reasons (especially for wireless device) that the source
> or sink could disappear at any time. Audio disappearing before or after
> the accompanying signaling furthermore a classic scenario which apps
> should be built to handle. So fixing the race (which i am not sure is
> really a race) does not seem like the correct solution. Trying to fix
> such "races" can lead to inefficiency by using unneeded timers and
> spin-locks, and will not provide robustness, as the audio streams can
> disappear for other reasons anyway.
100% agreed, arbitrary timers/timeouts are definable not robust and
iirc PA tries to be lock free.
On Wed, 2010-10-27 at 22:03 +0200, Thomas Wälti wrote:
> All works well except when ending the recording of Bluetooth
> Conversations: Once a party hangs up the call, the PulseAudio source
> and sink disappear before I can stop GStreamer recording (I'm
> listening to D-Bus events). Unfortunately, this causes my GStreamer
> pipeline to crash.
There are many reasons (especially for wireless device) that the source
or sink could disappear at any time. Audio disappearing before or after
the accompanying signaling furthermore a classic scenario which apps
should be built to handle. So fixing the race (which i am not sure is
really a race) does not seem like the correct solution. Trying to fix
such "races" can lead to inefficiency by using unneeded timers and
spin-locks, and will not provide robustness, as the audio streams can
disappear for other reasons anyway.
Maybe the crash is more interesting. What actually crashes when this
happens, and why?
Thanks,
/pedro
2010/10/28 Johan Hedberg <[email protected]>:
> Probably this isn't really BlueZ related, but the audio policy module
> (on the PulseAudio side) in the N900 kicks in and requests these changes
> to the audio streams. Unfortunately I'm not really an expert with that
> code (and afaik the audio policy part is closed) so I can't really offer
> more insight on the issue. Just speculating, but you might be able to
> accomplish something by hacking in some delays into the pulse bluetooth
> modules (but again, I'm not really familiar with them so this might not
> be a feasible approach).
Thanks for the prompt feedback, Johan.
I had looked at the PulseAudio Bluetooth Modules source
(http://git.0pointer.de/?p=pulseaudio.git;a=tree;f=src/modules/bluetooth;hb=HEAD)
before, but didn't see anything (but then, it's a bit over my head :-)
It seems like Joao Paulo Rechi Vita is the author of the relevant
source, and as he also did the Bluez HFP implementation (IIRC), I hope
he might shed a light on this. I'm asking on this list because once
HFP "hangs up", it probably issues some teardown event to its
consumers.
(It would be nice if I could get this solved this before heading to
the MeeGo conf in Dublin - see you there :-)
Best regards
-Tom
Hi Tom,
On Wed, Oct 27, 2010, Thomas W?lti wrote:
> I'm developing an application that records all kinds of audio using GStreamer.
> Target platform is the Nokia N900, the app is called Recaller
> (http://maemo.org/downloads/product/Maemo5/recaller/)
Looks like a pretty cool app!
> All works well except when ending the recording of Bluetooth
> Conversations: Once a party hangs up the call, the PulseAudio source
> and sink disappear before I can stop GStreamer recording (I'm
> listening to D-Bus events). Unfortunately, this causes my GStreamer
> pipeline to crash.
>
> Is there a way to either delay the destruction of the sink/source by
> Bluez or a D-Bus message I could intercept/attach to? How can I "win
> the race"?
Probably this isn't really BlueZ related, but the audio policy module
(on the PulseAudio side) in the N900 kicks in and requests these changes
to the audio streams. Unfortunately I'm not really an expert with that
code (and afaik the audio policy part is closed) so I can't really offer
more insight on the issue. Just speculating, but you might be able to
accomplish something by hacking in some delays into the pulse bluetooth
modules (but again, I'm not really familiar with them so this might not
be a feasible approach).
Johan
2010/10/31 Luiz Augusto von Dentz <[email protected]>:
>> On Wed, 2010-10-27 at 22:03 +0200, Thomas W?lti wrote:
>>
>>> All works well except when ending the recording of Bluetooth
>>> Conversations: Once a party hangs up the call, the PulseAudio source
>>> and sink disappear before I can stop GStreamer recording (I'm
>>> listening to D-Bus events). Unfortunately, this causes my GStreamer
>>> pipeline to crash.
>
> Well then there is a problem in your pipeline, bluetooth sinks and
> sources may disappear at any point and in fact PA do move audio,
> depending on the system policy, when that occurs. Also note that
> bluetooth modules do handle DisconnectRequest signal so it might react
> a bit faster when user request audio to be disconnected, but that
> should not make any difference for an application using PA.
Thanks everybody for the helpful comments and valuable details,
helping me to understand how the "underworld" of my app works in the
Bluez/PA corner.
I'll now shift my focus towards GStreamer :-)
Best regards
-Tom