Re: [pulseaudio-discuss] [PATCH v3 0/6] Remember card's "preferred ports"

[Arun Raghavan]

On 4 March 2016 at 18:53, Tanu Kaskinen  wrote:
> Changes in v3:
>   * fixed a couple of entry loading bugs in card-restore
>
> Changes in v2:
>   * moved the preferred port variables to pa_card
>   * implemented preferred port persistence with card-restore
>   * switch-on-port-available: update card_info->active_profile always
> in the profile changed hook callback, not only when the change is
> initiated by the user
>   * added the "avoid repetitive pointer deferencing" refactoring patch
>
> Tanu Kaskinen (6):
>   switch-on-port-available: unify input/output switching policy
>   switch-on-port-available: fix inverted if condition
>   switch-on-port-available: avoid repetitive pointer deferencing
>   card: add preferred_{input,output}_port
>   card-restore: restore preferred ports
>   switch-on-port-available: prefer ports that have been selected by the
> user

I've pushed the first 3 patches. Deferring the next 3 until we have
some consensus on the way forward on the bug
(https://bugs.freedesktop.org/show_bug.cgi?id=93946).

-- Arun
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Bluetooth A2DP AAC passthrough?

[Arun Raghavan]

On 2 May 2016 at 21:56, Pierre-Louis Bossart
 wrote:
> On 5/2/16 8:50 AM, Arun Raghavan wrote:
>>
>> On 2 May 2016 at 19:06, Pierre-Louis Bossart
>>  wrote:
>>>
>>> On 4/29/16 10:17 PM, Arun Raghavan wrote:


 On 29 April 2016 at 18:57, Tanu Kaskinen  wrote:
>
>
> On Wed, 2016-04-27 at 16:53 +0200, Nicole Færber wrote:
>>
>>
>> Hello,
>>
>> I know this has been a topic several times now. I searched the
>> mailinglist archives, FAQ, current GIT and other internet resources
>> for
>> a practical way with current versions of BlueZ5 and Pulse Audio but it
>> seems that most proposed patches have been dropped, am I correct with
>> this assessment?
>>
>> My personal goal would be to have a mode to playback AAC content to a
>> paired and connected A2DP device capable of A2DP-AAC - in my case a
>> Parrot Zik2.0. If such a way already exists I would be really happy
>> for
>> an advice on how to actually use it, e.g. using paplay?
>>
>> If such a mode does not yet exist are there plans to implement other
>> codecs? At least as pass-through? What is needed? Is it already being
>> worked on? Can I give a hand? As usual time is limited and my
>> knowledge
>> on A2DP and especially Pulse Audio is limited but I am willing to
>> help.
>
>
>
> Compressed audio passthrough with bluetooth is not supported. I think
> the feature would be welcome, though. I'm not aware of anyone working
> on it.
>
> We already support compressed passthrough with alsa, so it's not
> necessary to start from absolute scratch. Alsa wants compressed audio
> wrapped in "IEC 61937" encapsulation, and that format also makes it
> easier for pulseaudio to deal with the data, because the encapsulation
> makes it possible to convert between number of bytes and time (that is,
> a certain number of bytes always corresponds to the same amount of
> time, which isn't true with plain AAC audio). For that reason we
> require applications to do the encapsulation, so pulseaudio doesn't
> have to do any changes to the data.
>
> I suppose bluetooth doesn't use the IEC 61937 encapsulation, so the
> question arises if we should use it in pulseaudio when doing
> passthrough with bluetooth. I think it would make sense to use
> encapsulation at least in the initial implementation, because that
> would then retain the nice property that we don't have to understand
> anything about the AAC format as such. The bluetooth module would then
> have to do the unpacking of the AAC data from the IEC 61937
> encapsulation, which hopefully is reasonably straightforward.



 Pierre-Louis Bossart did a PoC based on this and I'd expanded on this
 a while back, for MP3:

   https://cgit.freedesktop.org/~arun/pulseaudio/log/?h=bt-passthrough

 However, this is a hack and doesn't make sense as the solution we
 upstream.

 We need to be able to deal with compressed audio as-is. The compressed
 API supports this at the ALSA layer, and I really want to be able to
 expose that cleanly. I'm not in favour of adding codec-specific code
 in PulseAudio, but I think it should be possible to have something
 working without that.
>>>
>>>
>>>
>>> Bluetooth adds format changes and RTP packetization that is not needed
>>> for
>>> compressed data playback in a sound card. if you are thinking of having a
>>> single layer to handle compressed playback, well, that is not going to
>>> work.
>>> You will need extra code in Bluetooth sinks.
>>>
>>> Specifically for AAC over A2DP the data needs to be reshuffled to add the
>>> LATM layer. The documentation for this is not quite self-explanatory.
>>
>>
>> We could push the reshuffling into LATM to a higher layer, same as for
>> the IEC61937 payloading, and we should be able to do the same for the
>> RTP payloading as well.
>
>
> Then this higher layer would need to have access to configuration parameters
> such as MTU, etc. Not sure how that information would be propagated.

Hmm, good point. We could have that on the format info of the sink.

> Regardless, if anyone wants AAC support it'd be easier to prototype with
> gstreamer and push the data into BlueZ. the integration in pulseaudio can be
> done later.
> If it helps here are some pointers
>
> https://developer.apple.com/hardwaredriver/BluetoothDesignGuidelines.pdf
> https://tools.ietf.org/html/rfc3016

You should be able to get an RTP/LATM stream with aacparse and
rtpmp4apay already.

Regards,
Arun
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] bluetooth latency gets gradually worse over time

[mudrunka]

Dne 2016-05-02 16:53, Jerome Leclanche napsal:
On Mon, May 2, 2016 at 5:06 PM, Arun Raghavan  
wrote:

On 1 May 2016 at 08:07,   wrote:

Hello,
i have issue with bluetooth speaker. it creates loud pop when it's
(un)suspended by module-suspend-on-idle. so i proceeded to disable
suspend-on-idle, but when i leave it on for few hours, the latency 
gets
huge. Like 2 seconds or more. I suppose it has something to do with 
DAC
clock (or samplerate) in bluetooth speakers being little bit slower 
than
nominal. And the error adds up over time resulting in growing 
latency.


When i manualy reconnect to speaker it gets fixed.

Do you have any idea how to fix this? I think it needs something that 
will
reset the stream when no audio is played, pretty much like 
suspend-on-idle
does, but without powering the bt device off (which causes pop). it's 
really
annoying. sometimes it scares the crap out of me, when speakers are 
on full
volume and it pops when i eg. receive IM mesage. :-) also it's 
probably not

healthy for the speakers (i use conventional speakers with amp and bt
receiver).

I know the popping is mostly HW error. But it can be worked around by
disabling suspend-on-idle, which then causes latency problems (also 
somehow
HW related). And i think the latency problem can be somehow fixed in 
SW by
restarting the stream or cleaning some buffer that causes the 
latency...


BTW 2 seconds of latency are quite a lot... Is there even chance, 
that cheap
BT device has 2 second buffer? Maybe it's pulse audio that has 2 
second

latency. And it would be easily fixed by not buffering silence. Or by
deleting this buffer when idle.


That does sound like a large latency. Could you file a bug about that,
and hopefully I'll get some time to test this out to see if it happens
locally too? If we do fix that, it looks like your problem should just
be fixed.

Cheers,
Arun
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss


I missed that original email, but this is something that's familiar to 
me.

I've been able to reproduce this exact issue very easily on the
bluetooth Parrot Zik and Parrot Zik 2 models with my btusb receiver by
running out of range of the receiver.
When out of range, a popping sound can be heard while the sound cuts
for a few milliseconds, and the sound then resumes where it initially
left off, creating a latency buffer which keeps growing every time the
headset goes out of range again.
The buffer resets when the card profile is turned off and back on (eg.
pactl set-card-profile bluez_card off && pactl set-card-profile
bluez_card a2dp_sink).

Worth noting the issue does not happen on the Parrot Zik 3, which is
compatible with Bluetooth 4.x (unlike the versions 1 and 2).

J. Leclanche



So do you think it will be possible to easily fix this in software for 
BT 2?
I think you are true that it's related to the signal. I think i've 
noticed it gets worse during signal disturbances...


Tomas



___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss


___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] need help building/cross compiling tests

[Peter Meerwald-Stadler]

Hi,

> I am trying to build tests. I was able to build them, but after running 
> them on target I am getting error:
> cann't find libcheck.so.0.

maybe not deployed to device?

> Does anybody know is libcheck is included in the pulseaudio sources?

no, it is not; maybe a build issue? maybe you libcheck locally install (so 
headers are available), but not as a dependency for cross-dev pulseaudio?

> Or has anybody cross compiled libcheck for arm-linux-gnueabi target?

http://libcheck.github.io/check/

regards, p.

-- 

Peter Meerwald-Stadler
+43-664-218 (mobile)
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

[pulseaudio-discuss] need help building/cross compiling tests

[Parag Borkar]

Hi,

I am trying to build tests. I was able to build them, but after running 
them on target I am getting error:

cann't find libcheck.so.0.
Does anybody know is libcheck is included in the pulseaudio sources?
Or has anybody cross compiled libcheck for arm-linux-gnueabi target?

Thanks & Regards,
Parag


___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Bluetooth A2DP AAC passthrough?

[Pierre-Louis Bossart]

On 5/2/16 8:50 AM, Arun Raghavan wrote:

On 2 May 2016 at 19:06, Pierre-Louis Bossart
 wrote:

On 4/29/16 10:17 PM, Arun Raghavan wrote:


On 29 April 2016 at 18:57, Tanu Kaskinen  wrote:


On Wed, 2016-04-27 at 16:53 +0200, Nicole Færber wrote:


Hello,

I know this has been a topic several times now. I searched the
mailinglist archives, FAQ, current GIT and other internet resources for
a practical way with current versions of BlueZ5 and Pulse Audio but it
seems that most proposed patches have been dropped, am I correct with
this assessment?

My personal goal would be to have a mode to playback AAC content to a
paired and connected A2DP device capable of A2DP-AAC - in my case a
Parrot Zik2.0. If such a way already exists I would be really happy for
an advice on how to actually use it, e.g. using paplay?

If such a mode does not yet exist are there plans to implement other
codecs? At least as pass-through? What is needed? Is it already being
worked on? Can I give a hand? As usual time is limited and my knowledge
on A2DP and especially Pulse Audio is limited but I am willing to help.



Compressed audio passthrough with bluetooth is not supported. I think
the feature would be welcome, though. I'm not aware of anyone working
on it.

We already support compressed passthrough with alsa, so it's not
necessary to start from absolute scratch. Alsa wants compressed audio
wrapped in "IEC 61937" encapsulation, and that format also makes it
easier for pulseaudio to deal with the data, because the encapsulation
makes it possible to convert between number of bytes and time (that is,
a certain number of bytes always corresponds to the same amount of
time, which isn't true with plain AAC audio). For that reason we
require applications to do the encapsulation, so pulseaudio doesn't
have to do any changes to the data.

I suppose bluetooth doesn't use the IEC 61937 encapsulation, so the
question arises if we should use it in pulseaudio when doing
passthrough with bluetooth. I think it would make sense to use
encapsulation at least in the initial implementation, because that
would then retain the nice property that we don't have to understand
anything about the AAC format as such. The bluetooth module would then
have to do the unpacking of the AAC data from the IEC 61937
encapsulation, which hopefully is reasonably straightforward.



Pierre-Louis Bossart did a PoC based on this and I'd expanded on this
a while back, for MP3:

  https://cgit.freedesktop.org/~arun/pulseaudio/log/?h=bt-passthrough

However, this is a hack and doesn't make sense as the solution we
upstream.

We need to be able to deal with compressed audio as-is. The compressed
API supports this at the ALSA layer, and I really want to be able to
expose that cleanly. I'm not in favour of adding codec-specific code
in PulseAudio, but I think it should be possible to have something
working without that.



Bluetooth adds format changes and RTP packetization that is not needed for
compressed data playback in a sound card. if you are thinking of having a
single layer to handle compressed playback, well, that is not going to work.
You will need extra code in Bluetooth sinks.

Specifically for AAC over A2DP the data needs to be reshuffled to add the
LATM layer. The documentation for this is not quite self-explanatory.


We could push the reshuffling into LATM to a higher layer, same as for
the IEC61937 payloading, and we should be able to do the same for the
RTP payloading as well.


Then this higher layer would need to have access to configuration 
parameters such as MTU, etc. Not sure how that information would be 
propagated.


Regardless, if anyone wants AAC support it'd be easier to prototype with 
gstreamer and push the data into BlueZ. the integration in pulseaudio 
can be done later.

If it helps here are some pointers

https://developer.apple.com/hardwaredriver/BluetoothDesignGuidelines.pdf
https://tools.ietf.org/html/rfc3016

___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] bluetooth latency gets gradually worse over time

[Arun Raghavan]

On 1 May 2016 at 08:07,   wrote:
> Hello,
> i have issue with bluetooth speaker. it creates loud pop when it's
> (un)suspended by module-suspend-on-idle. so i proceeded to disable
> suspend-on-idle, but when i leave it on for few hours, the latency gets
> huge. Like 2 seconds or more. I suppose it has something to do with DAC
> clock (or samplerate) in bluetooth speakers being little bit slower than
> nominal. And the error adds up over time resulting in growing latency.
>
> When i manualy reconnect to speaker it gets fixed.
>
> Do you have any idea how to fix this? I think it needs something that will
> reset the stream when no audio is played, pretty much like suspend-on-idle
> does, but without powering the bt device off (which causes pop). it's really
> annoying. sometimes it scares the crap out of me, when speakers are on full
> volume and it pops when i eg. receive IM mesage. :-) also it's probably not
> healthy for the speakers (i use conventional speakers with amp and bt
> receiver).
>
> I know the popping is mostly HW error. But it can be worked around by
> disabling suspend-on-idle, which then causes latency problems (also somehow
> HW related). And i think the latency problem can be somehow fixed in SW by
> restarting the stream or cleaning some buffer that causes the latency...
>
> BTW 2 seconds of latency are quite a lot... Is there even chance, that cheap
> BT device has 2 second buffer? Maybe it's pulse audio that has 2 second
> latency. And it would be easily fixed by not buffering silence. Or by
> deleting this buffer when idle.

That does sound like a large latency. Could you file a bug about that,
and hopefully I'll get some time to test this out to see if it happens
locally too? If we do fix that, it looks like your problem should just
be fixed.

Cheers,
Arun
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Add filter to module-switch-on-connect

[Arun Raghavan]

On 1 May 2016 at 07:36,   wrote:
> Hello,
> i've understood that i can use module-switch-on-connect to automatically
> switch to bluetooth speaker as soon as it gets connected. However i don't
> want this to happen for ethernet sinks. We have like 8 IP sinks in our
> network (randomly connecting and disconnecting - each station in our office
> has public pulseaudio server), so i guess it would be complete mess. But i'd
> still like to use them manually at will, but have it done automatically for
> paired bt devices.
>
> So i'd like module-switch-on-connect to have some optional whitelist of
> devices, so i can load it like eg.:
>
> load-module module-switch-on-connect
> whitelist='bluetooth:*,avahi:192.168.23.0/24,avahi:10.11.23.23'
>
> which would enable automatic switch for bt devices with any MAC, any
> avahi-discovered device in 192.168.23.0/24 subnet and avahi device on
> 10.11.23.23.
>
> What do you think about this concept? is it doable?

You could potentially add some code to filter on the sink flags before
connecting and not switch to sinks with the network flag (this could
be a modarg, with default behaviour being what you suggest).

This, coupled with something like Tanu's preferred port work
(https://patchwork.freedesktop.org/series/4093/) might get you what
you want -- you select your network sink once, and it should get
auto-selected the next time (ignoring the network flag checking
logic).

-- Arun
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Bluetooth A2DP AAC passthrough?

[Arun Raghavan]

On 2 May 2016 at 19:06, Pierre-Louis Bossart
 wrote:
> On 4/29/16 10:17 PM, Arun Raghavan wrote:
>>
>> On 29 April 2016 at 18:57, Tanu Kaskinen  wrote:
>>>
>>> On Wed, 2016-04-27 at 16:53 +0200, Nicole Færber wrote:

 Hello,

 I know this has been a topic several times now. I searched the
 mailinglist archives, FAQ, current GIT and other internet resources for
 a practical way with current versions of BlueZ5 and Pulse Audio but it
 seems that most proposed patches have been dropped, am I correct with
 this assessment?

 My personal goal would be to have a mode to playback AAC content to a
 paired and connected A2DP device capable of A2DP-AAC - in my case a
 Parrot Zik2.0. If such a way already exists I would be really happy for
 an advice on how to actually use it, e.g. using paplay?

 If such a mode does not yet exist are there plans to implement other
 codecs? At least as pass-through? What is needed? Is it already being
 worked on? Can I give a hand? As usual time is limited and my knowledge
 on A2DP and especially Pulse Audio is limited but I am willing to help.
>>>
>>>
>>> Compressed audio passthrough with bluetooth is not supported. I think
>>> the feature would be welcome, though. I'm not aware of anyone working
>>> on it.
>>>
>>> We already support compressed passthrough with alsa, so it's not
>>> necessary to start from absolute scratch. Alsa wants compressed audio
>>> wrapped in "IEC 61937" encapsulation, and that format also makes it
>>> easier for pulseaudio to deal with the data, because the encapsulation
>>> makes it possible to convert between number of bytes and time (that is,
>>> a certain number of bytes always corresponds to the same amount of
>>> time, which isn't true with plain AAC audio). For that reason we
>>> require applications to do the encapsulation, so pulseaudio doesn't
>>> have to do any changes to the data.
>>>
>>> I suppose bluetooth doesn't use the IEC 61937 encapsulation, so the
>>> question arises if we should use it in pulseaudio when doing
>>> passthrough with bluetooth. I think it would make sense to use
>>> encapsulation at least in the initial implementation, because that
>>> would then retain the nice property that we don't have to understand
>>> anything about the AAC format as such. The bluetooth module would then
>>> have to do the unpacking of the AAC data from the IEC 61937
>>> encapsulation, which hopefully is reasonably straightforward.
>>
>>
>> Pierre-Louis Bossart did a PoC based on this and I'd expanded on this
>> a while back, for MP3:
>>
>>   https://cgit.freedesktop.org/~arun/pulseaudio/log/?h=bt-passthrough
>>
>> However, this is a hack and doesn't make sense as the solution we
>> upstream.
>>
>> We need to be able to deal with compressed audio as-is. The compressed
>> API supports this at the ALSA layer, and I really want to be able to
>> expose that cleanly. I'm not in favour of adding codec-specific code
>> in PulseAudio, but I think it should be possible to have something
>> working without that.
>
>
> Bluetooth adds format changes and RTP packetization that is not needed for
> compressed data playback in a sound card. if you are thinking of having a
> single layer to handle compressed playback, well, that is not going to work.
> You will need extra code in Bluetooth sinks.
>
> Specifically for AAC over A2DP the data needs to be reshuffled to add the
> LATM layer. The documentation for this is not quite self-explanatory.

We could push the reshuffling into LATM to a higher layer, same as for
the IEC61937 payloading, and we should be able to do the same for the
RTP payloading as well.

-- Arun
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Bluetooth A2DP AAC passthrough?

[Pierre-Louis Bossart]

On 4/29/16 10:17 PM, Arun Raghavan wrote:

On 29 April 2016 at 18:57, Tanu Kaskinen  wrote:

On Wed, 2016-04-27 at 16:53 +0200, Nicole Færber wrote:

Hello,

I know this has been a topic several times now. I searched the
mailinglist archives, FAQ, current GIT and other internet resources for
a practical way with current versions of BlueZ5 and Pulse Audio but it
seems that most proposed patches have been dropped, am I correct with
this assessment?

My personal goal would be to have a mode to playback AAC content to a
paired and connected A2DP device capable of A2DP-AAC - in my case a
Parrot Zik2.0. If such a way already exists I would be really happy for
an advice on how to actually use it, e.g. using paplay?

If such a mode does not yet exist are there plans to implement other
codecs? At least as pass-through? What is needed? Is it already being
worked on? Can I give a hand? As usual time is limited and my knowledge
on A2DP and especially Pulse Audio is limited but I am willing to help.


Compressed audio passthrough with bluetooth is not supported. I think
the feature would be welcome, though. I'm not aware of anyone working
on it.

We already support compressed passthrough with alsa, so it's not
necessary to start from absolute scratch. Alsa wants compressed audio
wrapped in "IEC 61937" encapsulation, and that format also makes it
easier for pulseaudio to deal with the data, because the encapsulation
makes it possible to convert between number of bytes and time (that is,
a certain number of bytes always corresponds to the same amount of
time, which isn't true with plain AAC audio). For that reason we
require applications to do the encapsulation, so pulseaudio doesn't
have to do any changes to the data.

I suppose bluetooth doesn't use the IEC 61937 encapsulation, so the
question arises if we should use it in pulseaudio when doing
passthrough with bluetooth. I think it would make sense to use
encapsulation at least in the initial implementation, because that
would then retain the nice property that we don't have to understand
anything about the AAC format as such. The bluetooth module would then
have to do the unpacking of the AAC data from the IEC 61937
encapsulation, which hopefully is reasonably straightforward.


Pierre-Louis Bossart did a PoC based on this and I'd expanded on this
a while back, for MP3:

  https://cgit.freedesktop.org/~arun/pulseaudio/log/?h=bt-passthrough

However, this is a hack and doesn't make sense as the solution we upstream.

We need to be able to deal with compressed audio as-is. The compressed
API supports this at the ALSA layer, and I really want to be able to
expose that cleanly. I'm not in favour of adding codec-specific code
in PulseAudio, but I think it should be possible to have something
working without that.


Bluetooth adds format changes and RTP packetization that is not needed 
for compressed data playback in a sound card. if you are thinking of 
having a single layer to handle compressed playback, well, that is not 
going to work. You will need extra code in Bluetooth sinks.


Specifically for AAC over A2DP the data needs to be reshuffled to add 
the LATM layer. The documentation for this is not quite self-explanatory.




As a start, I'd look at just passing through data as is, and ignoring
latencies from PulseAudio buffering altogether on such streams.
Eventually, we might be able to explore options such as passing
additional duration metadata on buffers to be able to do accurate
latency reporting.

I think the LG folks had something along these lines, but I've not
heard from them about upstreaming their efforts in a while.

Cheers,
Arun
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss



___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss