Re: [pulseaudio-discuss] [PATCH v9 0/8] Bluetooth A2DP codecs
On Friday 26 April 2019 16:44:03 Luiz Augusto von Dentz wrote:
> Hi Pali,
>
> On Fri, Apr 26, 2019 at 1:55 PM Pali Rohár wrote:
> >
> > On Friday 26 April 2019 13:09:00 Luiz Augusto von Dentz wrote:
> > > Hi Pali,
> > >
> > > On Fri, Apr 26, 2019 at 11:34 AM Pali Rohár wrote:
> > > >
> > > > On Friday 26 April 2019 11:20:26 Luiz Augusto von Dentz wrote:
> > > > > I have an assert when I use a different headset which does support
> > > > > apt-X HD:
> > > > >
> > > > > https://gist.github.com/Vudentz/0d6b6f2ad08524db69a3e223e26bc80d
> > > >
> > > > I have not tested aptX HD, nor aptX Low Latency. I tested only (classic)
> > > > aptX. I looked at code and there is incorrect calculation of buffer
> > > > block size for aptX HD. Try following:
> > > >
> > > > static void get_buffer_size_hd(void *codec_info, size_t link_mtu,
> > > > size_t *decoded_buffer_size, size_t *encoded_buffer_size) {
> > > > /* aptX HD compression ratio is 4:1 and we need to process one aptX
> > > > HD sample (6 bytes) at once */
> > > > *encoded_buffer_size = (link_mtu/6) * 6;
> > > > *decoded_buffer_size = *encoded_buffer_size * 4;
> > > > }
> > >
> > > Will try, btw if I disable aptX HD it attempts to pick up UHQ2 but it
> > > asserts as well:
> > >
> > > https://gist.github.com/Vudentz/0e91f3ba260211cab38822bcf04edd1f
> > >
> > > It seems that fill_preferred_configuration and can_accept_capabilities
> > > are not agreeing with one another
> >
> > When fill_preferred_configuration or can_accept_capabilities fails it
> > prints debug message about it. But I do not see any of them in your
> > output. So I think problem can be somewhere else.
> >
> > I have not got this assert for uhq2, so this looks like some race
> > condition.
> >
> > > so we got a transport but no profile.
> >
> > In your log is:
> > bluez activated sbc_uhq2, then module-bluez5-device started to be
> > loading, card.c chose a2dp_sink_aptx as initial profile and due to bug
> > in module-bluetooth-policy.c aptx was not changed to sbc_uhq2. Next
> > sbc_uhq2 was released and prepared for switching to initial profile
> > aptx. And then assertion failed.
> >
> > My guess is: because card.c was not fully initialized yet (it called
> > hook for choosing initial profile), which called code for switching
> > profile, then u->card->profiles was not fully initialized and crashed.
> > Profile switching should be probably allowed only after full card
> > initialization to prevent such race conditions...
>
> Managed to find the problem, it was in choose_remote_endpoint_table:
>
>
> for (i = 0; i < PA_ELEMENTSOF(freq_table); i++) {
> if (freq_table[i].rate == default_sample_spec->rate) {
> -frequency = freq_table[i].rate;
> +frequency = freq_table[i].cap;
> break;
> }
Nice catch, thank you!
> I have not idea how this worked with the bose, maybe that has more
> frequencies enabled since I end up with 0x44 which did not match any
> frequencies supported in case of sony.
It worked also for me, so seems that more enabled frequencies was the
reason.
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: PGP signature
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v9 0/8] Bluetooth A2DP codecs
Hi Pali,
On Fri, Apr 26, 2019 at 1:55 PM Pali Rohár wrote:
>
> On Friday 26 April 2019 13:09:00 Luiz Augusto von Dentz wrote:
> > Hi Pali,
> >
> > On Fri, Apr 26, 2019 at 11:34 AM Pali Rohár wrote:
> > >
> > > On Friday 26 April 2019 11:20:26 Luiz Augusto von Dentz wrote:
> > > > I have an assert when I use a different headset which does support
> > > > apt-X HD:
> > > >
> > > > https://gist.github.com/Vudentz/0d6b6f2ad08524db69a3e223e26bc80d
> > >
> > > I have not tested aptX HD, nor aptX Low Latency. I tested only (classic)
> > > aptX. I looked at code and there is incorrect calculation of buffer
> > > block size for aptX HD. Try following:
> > >
> > > static void get_buffer_size_hd(void *codec_info, size_t link_mtu, size_t
> > > *decoded_buffer_size, size_t *encoded_buffer_size) {
> > > /* aptX HD compression ratio is 4:1 and we need to process one aptX
> > > HD sample (6 bytes) at once */
> > > *encoded_buffer_size = (link_mtu/6) * 6;
> > > *decoded_buffer_size = *encoded_buffer_size * 4;
> > > }
> >
> > Will try, btw if I disable aptX HD it attempts to pick up UHQ2 but it
> > asserts as well:
> >
> > https://gist.github.com/Vudentz/0e91f3ba260211cab38822bcf04edd1f
> >
> > It seems that fill_preferred_configuration and can_accept_capabilities
> > are not agreeing with one another
>
> When fill_preferred_configuration or can_accept_capabilities fails it
> prints debug message about it. But I do not see any of them in your
> output. So I think problem can be somewhere else.
>
> I have not got this assert for uhq2, so this looks like some race
> condition.
>
> > so we got a transport but no profile.
>
> In your log is:
> bluez activated sbc_uhq2, then module-bluez5-device started to be
> loading, card.c chose a2dp_sink_aptx as initial profile and due to bug
> in module-bluetooth-policy.c aptx was not changed to sbc_uhq2. Next
> sbc_uhq2 was released and prepared for switching to initial profile
> aptx. And then assertion failed.
>
> My guess is: because card.c was not fully initialized yet (it called
> hook for choosing initial profile), which called code for switching
> profile, then u->card->profiles was not fully initialized and crashed.
> Profile switching should be probably allowed only after full card
> initialization to prevent such race conditions...
Managed to find the problem, it was in choose_remote_endpoint_table:
for (i = 0; i < PA_ELEMENTSOF(freq_table); i++) {
if (freq_table[i].rate == default_sample_spec->rate) {
-frequency = freq_table[i].rate;
+frequency = freq_table[i].cap;
break;
}
I have not idea how this worked with the bose, maybe that has more
frequencies enabled since I end up with 0x44 which did not match any
frequencies supported in case of sony.
--
Luiz Augusto von Dentz
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] configure a soundcard?
On Fri, Apr 26, 2019 at 4:28 AM Tanu Kaskinen wrote: > > > Card #1 > > Name: alsa_card.pci-_00_14.2 > > ... > > > Ports: > > ... > > > analog-output-lineout: Line Out (priority: 9900, latency > > offset: 0 usec, not available) > > Part of profile(s): output:analog-stereo, > > output:analog-stereo+input:analog-stereo, output:analog-surround-21, > > output:analog-surround-21+input:analog-stereo, output:analog-surround-40, > > output:analog-surround-40+input:analog-stereo, output:analog-surround-41, > > output:analog-surround-41+input:analog-stereo, output:analog-surround-50, > > output:analog-surround-50+input:analog-stereo, output:analog-surround-51, > > output:analog-surround-51+input:analog-stereo, output:analog-surround-71, > > output:analog-surround-71+input:analog-stereo > > analog-output-headphones: Headphones (priority: 9000, > > latency offset: 0 usec, not available) > > Properties: > > device.icon_name = "audio-headphones" > > Part of profile(s): output:analog-stereo, > > output:analog-stereo+input:analog-stereo > > iec958-stereo-output: Digital Output (S/PDIF) (priority: > 0, > > latency offset: 0 usec) > > Part of profile(s): output:iec958-stereo, > > output:iec958-stereo+input:analog-stereo > > Both analog ports are marked as "not available", which means that to > PulseAudio looks like nothing is plugged in in either connector. This > is the reason why PulseAudio always picks the digital output on boot. > Broken jack detection is is a hardware or driver issue, which can be > worked around, see below. > Ahhh. Understood. > > > while read -r line; do amixer -c0 cget "$line"; done <<< $(amixer > -c0 > > > controls | grep Jack) > > > > > > > numid=1,iface=CARD,name='HDMI/DP,pcm=3 Jack' > > ; type=BOOLEAN,access=r---,values=1 > > : values=on > > numid=7,iface=CARD,name='HDMI/DP,pcm=7 Jack' > > ; type=BOOLEAN,access=r---,values=1 > > : values=off > > It seems that I guessed wrong the card number. Card 0 seems to be the > HDMI card, while we're interested in the analog sound card, which is > alsa card 1. So change the script to this: > > while read -r line; do amixer -c0 cget "$line"; done <<< $(amixer -c0 > controls | grep Jack) > I'm guessing I should change the above -c0's to -c1's. Here is that output: numid=44,iface=CARD,name='CD Phantom Jack' ; type=BOOLEAN,access=r---,values=1 : values=on numid=49,iface=CARD,name='Front Headphone Jack' ; type=BOOLEAN,access=r---,values=1 : values=off numid=42,iface=CARD,name='Front Mic Jack' ; type=BOOLEAN,access=r---,values=1 : values=off numid=43,iface=CARD,name='Line Jack' ; type=BOOLEAN,access=r---,values=1 : values=off numid=47,iface=CARD,name='Line Out CLFE Jack' ; type=BOOLEAN,access=r---,values=1 : values=off numid=45,iface=CARD,name='Line Out Front Jack' ; type=BOOLEAN,access=r---,values=1 : values=off numid=48,iface=CARD,name='Line Out Side Jack' ; type=BOOLEAN,access=r---,values=1 : values=off numid=46,iface=CARD,name='Line Out Surround Jack' ; type=BOOLEAN,access=r---,values=1 : values=off numid=41,iface=CARD,name='Rear Mic Jack' ; type=BOOLEAN,access=r---,values=1 : values=off numid=50,iface=CARD,name='SPDIF Jack' ; type=BOOLEAN,access=r---,values=1 : values=off This information is required for me to give instructions for how to > work around the issue. > Okay. Thanks for all your help! -m ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] pulseaudio still running before shutdown
Hello Tanu, thanks for your reply. I just looked it up : ps -aux | grep -i pulseaudio rosika 1539 0.0 0.4 976248 17244 ? Sl 12:54 0:00 /usr/bin/pulseaudio --start --log-target=syslog rosika 2870 0.1 0.4 443636 16320 ? Sl 13:00 0:01 /usr/bin/pulseaudio --start --log-target=syslog rosika 3276 0.0 0.0 21536 1048 pts/2 S+ 13:20 0:00 grep --color=auto -i pulseaudio So for both processes I seem to be the user. Strange. As display manager I guess I have lightdm, as I use Lubuntu. Nevertheless I´ll try setting "exit-idle-time = 0" in /etc/pulse/daemon.conf . Gretings. Rosika Am 26.04.19 um 10:22 schrieb Tanu Kaskinen: > P.S.: >> I still don´t understand why there are *two *proceses running before >> shutdown: >> >> ps -ax | grep -i pulseaudio >> 1515 ?Sl 0:00 /usr/bin/pulseaudio --start --log-target=syslog >> 2348 ?Sl 0:01 /usr/bin/pulseaudio --start --log-target=syslog >> 3820 pts/2S+ 0:00 grep --color=auto -i pulseaudio > I would guess the other one is for gdm. You can use "pa aux" to see > also the user of the process. > ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v9 0/8] Bluetooth A2DP codecs
On Friday 26 April 2019 13:09:00 Luiz Augusto von Dentz wrote:
> Hi Pali,
>
> On Fri, Apr 26, 2019 at 11:34 AM Pali Rohár wrote:
> >
> > On Friday 26 April 2019 11:20:26 Luiz Augusto von Dentz wrote:
> > > I have an assert when I use a different headset which does support apt-X
> > > HD:
> > >
> > > https://gist.github.com/Vudentz/0d6b6f2ad08524db69a3e223e26bc80d
> >
> > I have not tested aptX HD, nor aptX Low Latency. I tested only (classic)
> > aptX. I looked at code and there is incorrect calculation of buffer
> > block size for aptX HD. Try following:
> >
> > static void get_buffer_size_hd(void *codec_info, size_t link_mtu, size_t
> > *decoded_buffer_size, size_t *encoded_buffer_size) {
> > /* aptX HD compression ratio is 4:1 and we need to process one aptX HD
> > sample (6 bytes) at once */
> > *encoded_buffer_size = (link_mtu/6) * 6;
> > *decoded_buffer_size = *encoded_buffer_size * 4;
> > }
>
> Will try, btw if I disable aptX HD it attempts to pick up UHQ2 but it
> asserts as well:
>
> https://gist.github.com/Vudentz/0e91f3ba260211cab38822bcf04edd1f
>
> It seems that fill_preferred_configuration and can_accept_capabilities
> are not agreeing with one another
When fill_preferred_configuration or can_accept_capabilities fails it
prints debug message about it. But I do not see any of them in your
output. So I think problem can be somewhere else.
I have not got this assert for uhq2, so this looks like some race
condition.
> so we got a transport but no profile.
In your log is:
bluez activated sbc_uhq2, then module-bluez5-device started to be
loading, card.c chose a2dp_sink_aptx as initial profile and due to bug
in module-bluetooth-policy.c aptx was not changed to sbc_uhq2. Next
sbc_uhq2 was released and prepared for switching to initial profile
aptx. And then assertion failed.
My guess is: because card.c was not fully initialized yet (it called
hook for choosing initial profile), which called code for switching
profile, then u->card->profiles was not fully initialized and crashed.
Profile switching should be probably allowed only after full card
initialization to prevent such race conditions...
--
Pali Rohár
pali.ro...@gmail.com
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v9 0/8] Bluetooth A2DP codecs
Hi Pali,
On Fri, Apr 26, 2019 at 11:34 AM Pali Rohár wrote:
>
> On Friday 26 April 2019 11:20:26 Luiz Augusto von Dentz wrote:
> > I have an assert when I use a different headset which does support apt-X HD:
> >
> > https://gist.github.com/Vudentz/0d6b6f2ad08524db69a3e223e26bc80d
>
> I have not tested aptX HD, nor aptX Low Latency. I tested only (classic)
> aptX. I looked at code and there is incorrect calculation of buffer
> block size for aptX HD. Try following:
>
> static void get_buffer_size_hd(void *codec_info, size_t link_mtu, size_t
> *decoded_buffer_size, size_t *encoded_buffer_size) {
> /* aptX HD compression ratio is 4:1 and we need to process one aptX HD
> sample (6 bytes) at once */
> *encoded_buffer_size = (link_mtu/6) * 6;
> *decoded_buffer_size = *encoded_buffer_size * 4;
> }
Will try, btw if I disable aptX HD it attempts to pick up UHQ2 but it
asserts as well:
https://gist.github.com/Vudentz/0e91f3ba260211cab38822bcf04edd1f
It seems that fill_preferred_configuration and can_accept_capabilities
are not agreeing with one another, so we got a transport but no
profile.
--
Luiz Augusto von Dentz
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] R: New equalizer module (module-eqpro-sink), some questions
On 26.04.19 10:56, Tanu Kaskinen wrote:
On Tue, 2019-04-23 at 21:20 +0200, Georg Chini wrote:
The current scheme for
updating
parameters I have in mind should work for any of the existing filters
and relies on
passing around parameter structures:
/* The following functions can be provided to set and get
parameters. The parameter
* structure is defined by the filter and should contain all
parameters that are
* configurable by the user. The library code makes no assumption
on the contents
* of the structure but only passes references. The library
implements a message
* handler which supports the following messages that use the
functions below:
* get_parameter - Retrieve a single parameter.
* set_parameter - Set a single parameter.
* get_all_parameters - Retrieve all parameters as a comma
separated list.
* set_all_parameters - Set all parameters simultaneously.
* get_parameter_description - Returns a list that describes all
parameters.
* Format of the list elements is:
* {{Identifier}{Type}{default}{min}{max}}
* The last message can be used to get information about the filter
or to implement
* a filter control GUI that is independent of the filter type. */
/* Get the value of the parameter described by identifier. The
value shall be returned
* as a string in value. The identifier may be any string that the
filter recognizes
* like a name or index, depending of the implementation of this
function. */
int (*parameter_get)(const char *identifier, char **value, void
*userdata);
/* Sets the value of the parameter described by identifier. The
value is expected as
* a string. The identifier may be any string that the filter
recognizes like a name
* or index. Returns a parameter structure filled with all current
parameter values,
* reflecting the updated parameter, so that the structure can be
passed to
* update_filter_parameter(). update_filter_parameter() will
replace the current
* parameter set with the new structure. */
void *(*parameter_set)(const char *identifier, const char *value,
void *userdata);
/* Returns a comma separated list of the values of all filter
parameters. */
char *(*parameter_get_all)(void *userdata);
/* Expects a comma separated list of all filter parameter values
and returns a parameter
* structure that can be passed to update_filter_parameters(). See
set_parameter(). */
void *(*parameter_set_all(const char *all_params, void *userdata);
/* Returns a parameter description string as described above. */
Some comments on the interface:
Thanks, that was what I hoped for.
"Parameters as a comma separated list" sounds potentially problematic
if the specification extends to the public API as well, unless all
possible parameter types are defined to not contain commas. Why is the
list not encoded in the same way other lists are encoded in the message
API?
It surely can be encoded the same way, but currently the
parameters for the LADSPA sink can be specified on the
command line as a comma separated list, so I thought it
would be a good idea to keep that format and allow other
filters to do the same thing. I do not think it is a big restriction
to not allow commas in the parameters. I can think of
following parameter types: Int (signed and unsigned), float,
bool and string. Only the string type would have a problem
and we could use escaping there. Or do I miss something?
The comma separated list is easier to understand for users
of the interface.
"{{Identifier}{Type}{default}{min}{max}}" is probably too strict for
the parameter description specification, if it extends to the public
API as well. Min/max only works for range values, but I can imagine
some filter having a "choose one from a list of non-numeric options". I
think the structure after {default} should be dependent on the
parameter type.
It was just the first idea. I am aware that what exactly is passed
in the description list should be discussed carefully. The basic
idea is that in the end there can be a GUI that checks which
message handlers are installed, gets the parameter description
from all loaded filters and displays multiple tabs with the controls
for each filter, regardless which type of filter is loaded. Once signals
are available as well, the GUI could subscribe to creation/removal
signals of message handlers to keep track of loaded filters. ( I am
not very good at writing GUI's, so I would leave that task to somebody
else.)
This would allocate the memory in the main thread but would require that
the I/O-thread frees the old parameter structure when it is replaced.
Alternatively
the function that replaces the old structure with the new one could return a
pointer to the old structure, so that it can be freed in the main thread.
That should work. The structures probably have
Re: [pulseaudio-discuss] configure a soundcard?
On Mon, 2019-04-22 at 07:47 -0500, Matt Zagrabelny wrote: > On Mon, Apr 22, 2019 at 3:06 AM Tanu Kaskinen wrote: > > > On Sat, 2019-04-20 at 12:11 -0500, Matt Zagrabelny wrote: > > > Greetings, > > > > > > I'm running Debian Buster and I have a 1/8" audio jack. I need the sink > > to > > > be an analog output to send off to some other device. Things work great, > > > except for when the system reboots, it comes up configured as a digital > > > soundcard: > > > > > > Digital Stereo (IEC958) > > > > > > Here is a diff between a "pactl list" when the computer reboots and when > > > I've configured it to be an analog sink: > > > > > > -Sink #1 > > > - State: SUSPENDED > > > - Name: alsa_output.pci-_00_14.2.iec958-stereo > > > - Description: Built-in Audio Digital Stereo (IEC958) > > > +Sink #2 > > > + State: RUNNING > > > + Name: alsa_output.pci-_00_14.2.analog-stereo > > > + Description: Built-in Audio Analog Stereo > > > > > > What is the best way to have the configuration saved between reboots? > > > > > > I can provide further info if needed. > > > > > > Thanks for any help! > > Hey Tanu! > > Thanks for the assistance. Below is the output of what you asked for. > Card #1 > Name: alsa_card.pci-_00_14.2 ... > Ports: ... > analog-output-lineout: Line Out (priority: 9900, latency > offset: 0 usec, not available) > Part of profile(s): output:analog-stereo, > output:analog-stereo+input:analog-stereo, output:analog-surround-21, > output:analog-surround-21+input:analog-stereo, output:analog-surround-40, > output:analog-surround-40+input:analog-stereo, output:analog-surround-41, > output:analog-surround-41+input:analog-stereo, output:analog-surround-50, > output:analog-surround-50+input:analog-stereo, output:analog-surround-51, > output:analog-surround-51+input:analog-stereo, output:analog-surround-71, > output:analog-surround-71+input:analog-stereo > analog-output-headphones: Headphones (priority: 9000, > latency offset: 0 usec, not available) > Properties: > device.icon_name = "audio-headphones" > Part of profile(s): output:analog-stereo, > output:analog-stereo+input:analog-stereo > iec958-stereo-output: Digital Output (S/PDIF) (priority: 0, > latency offset: 0 usec) > Part of profile(s): output:iec958-stereo, > output:iec958-stereo+input:analog-stereo Both analog ports are marked as "not available", which means that to PulseAudio looks like nothing is plugged in in either connector. This is the reason why PulseAudio always picks the digital output on boot. Broken jack detection is is a hardware or driver issue, which can be worked around, see below. > > while read -r line; do amixer -c0 cget "$line"; done <<< $(amixer -c0 > > controls | grep Jack) > > > > numid=1,iface=CARD,name='HDMI/DP,pcm=3 Jack' > ; type=BOOLEAN,access=r---,values=1 > : values=on > numid=7,iface=CARD,name='HDMI/DP,pcm=7 Jack' > ; type=BOOLEAN,access=r---,values=1 > : values=off It seems that I guessed wrong the card number. Card 0 seems to be the HDMI card, while we're interested in the analog sound card, which is alsa card 1. So change the script to this: while read -r line; do amixer -c0 cget "$line"; done <<< $(amixer -c0 controls | grep Jack) This information is required for me to give instructions for how to work around the issue. -- Tanu https://www.patreon.com/tanuk https://liberapay.com/tanuk ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v9 0/8] Bluetooth A2DP codecs
On Thu, 2019-04-25 at 19:03 +0200, Pali Rohár wrote: > On Thursday 25 April 2019 18:54:05 Pali Rohár wrote: > > On Thursday 25 April 2019 18:51:49 Pali Rohár wrote: > > > On Thursday 25 April 2019 19:43:28 Luiz Augusto von Dentz wrote: > > > > Hi Pali, > > > > > > > > On Thu, Apr 25, 2019 at 2:42 PM Luiz Augusto von Dentz > > > > wrote: > > > > > Hi Pali, > > > > > > > > > > On Thu, Apr 25, 2019 at 2:35 PM Pali Rohár > > > > > wrote: > > > > > > On Thursday 25 April 2019 13:28:16 Pali Rohár wrote: > > > > > > > On Thursday 25 April 2019 14:19:15 Luiz Augusto von Dentz wrote: > > > > > > > > These seems to work great, I can even switch on the fly the > > > > > > > > profiles > > > > > > > > and after a short delay it switches without a problem, there is > > > > > > > > one > > > > > > > > issue related to reconnecting though: > > > > > > > > > > > > > > > > https://gist.github.com/Vudentz/40f10e85fb860083958edae67093f016 > > > > > > > > > > > > > > > > With BlueZ remembering the last used endpoint (aptX) it seems > > > > > > > > the > > > > > > > > policy ignores that and reverts to highest priority (SBC UHQ), > > > > > > > > > > > > Relevant lines: > > > > > > > > > > > > D: [lt-pulseaudio] bluez5-util.c: Transport > > > > > > /org/bluez/hci0/dev_94_20_53_2E_08_CE/sep5/fd26 available for > > > > > > profile a2dp_sink_aptx > > > > > > ... > > > > > > D: [lt-pulseaudio] card.c: a2dp_sink_aptx availability unknown > > > > > > ... > > > > > > D: [lt-pulseaudio] card.c: off availability yes > > > > > > I: [lt-pulseaudio] card.c: bluez_card.94_20_53_2E_08_CE: > > > > > > active_profile: a2dp_sink_sbc_uhq2 > > > > > > D: [lt-pulseaudio] module-bluetooth-policy.c: Looking for A2DP > > > > > > profile activated by bluez for card bluez_card.94_20_53_2E_08_CE > > > > > > I: [lt-pulseaudio] card.c: Created 5 "bluez_card.94_20_53_2E_08_CE" > > > > > > > > > > > > We got information that sep5 is activated with fd26 and it > > > > > > corespondent > > > > > > to profile a2dp_sink_aptx. And on next lines we see that profile has > > > > > > unknown availability -- which means that it is possible to switch to > > > > > > that codec/profile, but it is not activated yet. On next lines we > > > > > > see > > > > > > that module-bluetooth-policy is trying to find "a2dp_*" which has > > > > > > availability "on", but there is no one. So initial profile stay > > > > > > a2dp_sink_sbc_uhq2 which was chosen as default by card.c. > > > > > > > > > > > > So problem is why a2dp_sink_aptx profile has unknown availability > > > > > > even > > > > > > it is activated? It should have "on" availability. And then policy > > > > > > choose it as initial. > > > > > > > > > > Right, looks like the state is not correct since it has a fd already > > > > > it should have been marked available. > > > > > > > > Problem seems to be that we need to set the transport state to playing > > > > since we introduce the following code: > > > > > > > > if (cp->available == PA_AVAILABLE_NO && > > > > u->support_a2dp_codec_switch && pa_bluetooth_profile_is_a2dp(profile)) > > > > cp->available = PA_AVAILABLE_UNKNOWN; > > > > > > > > That means every A2DP profile will be set to unknown including even if > > > > they have no transport yet > > > > > > That is truth. But if there is a transport then availability is YES. > > > > > > Availability NO is used when it is not possible to activate transport > > > because it is unsupported (e.g. A2DP not connected or when bluez does > > > not support profile switching). > > > > > > > so now we have to set the initial transport to playing > > > > > > How it should help? I do not see reason now... > > > > > > Anyway, I was not able to reproduce your problem, basically I always had > > > availability for activated profile set to YES. > > > > Now I see it. PA_AVAILABLE_YES is returned only for > > PA_BLUETOOTH_TRANSPORT_STATE_PLAYING. > > > > So for PA_BLUETOOTH_TRANSPORT_STATE_IDLE we also get > > PA_AVAILABLE_UNKNOWN and therefore module-bluetooth-policy does not know > > which transport is activated. > > > > Cannot we get transport state in module-bluetooth-policy? Seems that > > this is the right direction. > > Currently we have following mapping: > > PA_BLUETOOTH_TRANSPORT_STATE_DISCONNECTED --> PA_AVAILABLE_NO > PA_BLUETOOTH_TRANSPORT_STATE_PLAYING --> PA_AVAILABLE_YES > PA_BLUETOOTH_TRANSPORT_STATE_IDLE --> PA_AVAILABLE_UNKNOWN > > Plus PA_AVAILABLE_NO is changed to PA_AVAILABLE_UNKNOWN when pulseaudio > can activate that transport via bluez codec switch API as described > above. > > PA_PORT_AVAILABLE_YES is defined as: > This port is available, likely because the jack is plugged in. > > PA_PORT_AVAILABLE_NO as: > This port is not available, likely because the jack is not plugged in. > > And PA_PORT_AVAILABLE_UNKNOWN as: > This port does not support jack detection > > Seems that PA code and applications skips profiles with PA_AVAILABLE_NO > and do not allow to use it.
Re: [pulseaudio-discuss] [PATCH v9 0/8] Bluetooth A2DP codecs
On Thu, 2019-04-25 at 18:54 +0200, Pali Rohár wrote: > On Thursday 25 April 2019 18:51:49 Pali Rohár wrote: > > On Thursday 25 April 2019 19:43:28 Luiz Augusto von Dentz wrote: > > > Hi Pali, > > > > > > On Thu, Apr 25, 2019 at 2:42 PM Luiz Augusto von Dentz > > > wrote: > > > > Hi Pali, > > > > > > > > On Thu, Apr 25, 2019 at 2:35 PM Pali Rohár wrote: > > > > > On Thursday 25 April 2019 13:28:16 Pali Rohár wrote: > > > > > > On Thursday 25 April 2019 14:19:15 Luiz Augusto von Dentz wrote: > > > > > > > These seems to work great, I can even switch on the fly the > > > > > > > profiles > > > > > > > and after a short delay it switches without a problem, there is > > > > > > > one > > > > > > > issue related to reconnecting though: > > > > > > > > > > > > > > https://gist.github.com/Vudentz/40f10e85fb860083958edae67093f016 > > > > > > > > > > > > > > With BlueZ remembering the last used endpoint (aptX) it seems the > > > > > > > policy ignores that and reverts to highest priority (SBC UHQ), > > > > > > > > > > Relevant lines: > > > > > > > > > > D: [lt-pulseaudio] bluez5-util.c: Transport > > > > > /org/bluez/hci0/dev_94_20_53_2E_08_CE/sep5/fd26 available for profile > > > > > a2dp_sink_aptx > > > > > ... > > > > > D: [lt-pulseaudio] card.c: a2dp_sink_aptx availability unknown > > > > > ... > > > > > D: [lt-pulseaudio] card.c: off availability yes > > > > > I: [lt-pulseaudio] card.c: bluez_card.94_20_53_2E_08_CE: > > > > > active_profile: a2dp_sink_sbc_uhq2 > > > > > D: [lt-pulseaudio] module-bluetooth-policy.c: Looking for A2DP > > > > > profile activated by bluez for card bluez_card.94_20_53_2E_08_CE > > > > > I: [lt-pulseaudio] card.c: Created 5 "bluez_card.94_20_53_2E_08_CE" > > > > > > > > > > We got information that sep5 is activated with fd26 and it > > > > > corespondent > > > > > to profile a2dp_sink_aptx. And on next lines we see that profile has > > > > > unknown availability -- which means that it is possible to switch to > > > > > that codec/profile, but it is not activated yet. On next lines we see > > > > > that module-bluetooth-policy is trying to find "a2dp_*" which has > > > > > availability "on", but there is no one. So initial profile stay > > > > > a2dp_sink_sbc_uhq2 which was chosen as default by card.c. > > > > > > > > > > So problem is why a2dp_sink_aptx profile has unknown availability even > > > > > it is activated? It should have "on" availability. And then policy > > > > > choose it as initial. > > > > > > > > Right, looks like the state is not correct since it has a fd already > > > > it should have been marked available. > > > > > > Problem seems to be that we need to set the transport state to playing > > > since we introduce the following code: > > > > > > if (cp->available == PA_AVAILABLE_NO && > > > u->support_a2dp_codec_switch && pa_bluetooth_profile_is_a2dp(profile)) > > > cp->available = PA_AVAILABLE_UNKNOWN; > > > > > > That means every A2DP profile will be set to unknown including even if > > > they have no transport yet > > > > That is truth. But if there is a transport then availability is YES. > > > > Availability NO is used when it is not possible to activate transport > > because it is unsupported (e.g. A2DP not connected or when bluez does > > not support profile switching). > > > > > so now we have to set the initial transport to playing > > > > How it should help? I do not see reason now... > > > > Anyway, I was not able to reproduce your problem, basically I always had > > availability for activated profile set to YES. > > Now I see it. PA_AVAILABLE_YES is returned only for > PA_BLUETOOTH_TRANSPORT_STATE_PLAYING. > > So for PA_BLUETOOTH_TRANSPORT_STATE_IDLE we also get > PA_AVAILABLE_UNKNOWN and therefore module-bluetooth-policy does not know > which transport is activated. > > Cannot we get transport state in module-bluetooth-policy? Seems that > this is the right direction. Yes, I think module-bluetooth-policy should look at the transport states directly, if that provides better information than the profile availability. -- Tanu https://www.patreon.com/tanuk https://liberapay.com/tanuk ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] R: New equalizer module (module-eqpro-sink), some questions
On Tue, 2019-04-23 at 21:20 +0200, Georg Chini wrote:
> On 22.04.19 09:34, Tanu Kaskinen wrote:
> > On Sat, 2019-04-20 at 11:38 +0200, Georg Chini wrote:
> > > PA uses malloc() in the IO-thread, so are we doing things wrong?
> > > I think using malloc() when a parameter changes is not interfering
> > > with real-time operation because the filter must be reset after
> > > a parameter change anyway.
> Am I allowed to use free() from the I/O-thread?
No. To my knowledge a lot of the memory management work may actually
happen in free() rather than malloc().
> The current scheme for
> updating
> parameters I have in mind should work for any of the existing filters
> and relies on
> passing around parameter structures:
>
>
> /* The following functions can be provided to set and get
> parameters. The parameter
> * structure is defined by the filter and should contain all
> parameters that are
> * configurable by the user. The library code makes no assumption
> on the contents
> * of the structure but only passes references. The library
> implements a message
> * handler which supports the following messages that use the
> functions below:
> * get_parameter - Retrieve a single parameter.
> * set_parameter - Set a single parameter.
> * get_all_parameters - Retrieve all parameters as a comma
> separated list.
> * set_all_parameters - Set all parameters simultaneously.
> * get_parameter_description - Returns a list that describes all
> parameters.
> * Format of the list elements is:
> * {{Identifier}{Type}{default}{min}{max}}
> * The last message can be used to get information about the filter
> or to implement
> * a filter control GUI that is independent of the filter type. */
>
> /* Get the value of the parameter described by identifier. The
> value shall be returned
> * as a string in value. The identifier may be any string that the
> filter recognizes
> * like a name or index, depending of the implementation of this
> function. */
> int (*parameter_get)(const char *identifier, char **value, void
> *userdata);
>
> /* Sets the value of the parameter described by identifier. The
> value is expected as
> * a string. The identifier may be any string that the filter
> recognizes like a name
> * or index. Returns a parameter structure filled with all current
> parameter values,
> * reflecting the updated parameter, so that the structure can be
> passed to
> * update_filter_parameter(). update_filter_parameter() will
> replace the current
> * parameter set with the new structure. */
> void *(*parameter_set)(const char *identifier, const char *value,
> void *userdata);
>
> /* Returns a comma separated list of the values of all filter
> parameters. */
> char *(*parameter_get_all)(void *userdata);
>
> /* Expects a comma separated list of all filter parameter values
> and returns a parameter
> * structure that can be passed to update_filter_parameters(). See
> set_parameter(). */
> void *(*parameter_set_all(const char *all_params, void *userdata);
>
> /* Returns a parameter description string as described above. */
Some comments on the interface:
"Parameters as a comma separated list" sounds potentially problematic
if the specification extends to the public API as well, unless all
possible parameter types are defined to not contain commas. Why is the
list not encoded in the same way other lists are encoded in the message
API?
"{{Identifier}{Type}{default}{min}{max}}" is probably too strict for
the parameter description specification, if it extends to the public
API as well. Min/max only works for range values, but I can imagine
some filter having a "choose one from a list of non-numeric options". I
think the structure after {default} should be dependent on the
parameter type.
> This would allocate the memory in the main thread but would require that
> the I/O-thread frees the old parameter structure when it is replaced.
> Alternatively
> the function that replaces the old structure with the new one could return a
> pointer to the old structure, so that it can be freed in the main thread.
That should work. The structures probably have fixed size, though, in
which case malloc()/free() can be avoided altogether: the filters can
allocate two instances of the internal structures during intialization
and switch between them when parameters are updated.
--
Tanu
https://www.patreon.com/tanuk
https://liberapay.com/tanuk
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v9 0/8] Bluetooth A2DP codecs
On Friday 26 April 2019 11:20:26 Luiz Augusto von Dentz wrote:
> I have an assert when I use a different headset which does support apt-X HD:
>
> https://gist.github.com/Vudentz/0d6b6f2ad08524db69a3e223e26bc80d
I have not tested aptX HD, nor aptX Low Latency. I tested only (classic)
aptX. I looked at code and there is incorrect calculation of buffer
block size for aptX HD. Try following:
static void get_buffer_size_hd(void *codec_info, size_t link_mtu, size_t
*decoded_buffer_size, size_t *encoded_buffer_size) {
/* aptX HD compression ratio is 4:1 and we need to process one aptX HD
sample (6 bytes) at once */
*encoded_buffer_size = (link_mtu/6) * 6;
*decoded_buffer_size = *encoded_buffer_size * 4;
}
--
Pali Rohár
pali.ro...@gmail.com
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] pulseaudio still running before shutdown
On Mon, 2019-04-22 at 12:58 +0200, Christian wrote: > Hi Tanu, > > thanks a lot for your answer and suggestion. > > First of all I have to apologize for getting something wrong. > I wrote: > > "I don´t know why I get this message because the shutdown works well > despite that error message. In fact it shuts down really fast." > > That´s /incorrect/. In fact it´s like this: the fact that pulseaudio is > still running indeed *prevents the shutdown *. > I mixed it up with another project of mine. Sorry about that. > > Now to your suggestion: > > I looked up _/etc/pulse/daemon.conf_. > > The "exit-idle-time"-value is currently set like so: > > ; exit-idle-time = 20 > > The man-pages say: "Terminate the daemon after the last client quit and > this time in seconds passed." > > Well, I think with the semicolon in front that value wasn´t set at all, right? > So I´d have to get rid of the semicolon and then set "exit-idle-time = 0". > > Would that be the way to go? Yes. > P.S.: > I still don´t understand why there are *two *proceses running before shutdown: > > ps -ax | grep -i pulseaudio > 1515 ?Sl 0:00 /usr/bin/pulseaudio --start --log-target=syslog > 2348 ?Sl 0:01 /usr/bin/pulseaudio --start --log-target=syslog > 3820 pts/2S+ 0:00 grep --color=auto -i pulseaudio I would guess the other one is for gdm. You can use "pa aux" to see also the user of the process. -- Tanu https://www.patreon.com/tanuk https://liberapay.com/tanuk ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v9 0/8] Bluetooth A2DP codecs
Hi Pali, On Thu, Apr 25, 2019 at 8:03 PM Pali Rohár wrote: > > On Thursday 25 April 2019 18:54:05 Pali Rohár wrote: > > On Thursday 25 April 2019 18:51:49 Pali Rohár wrote: > > > On Thursday 25 April 2019 19:43:28 Luiz Augusto von Dentz wrote: > > > > Hi Pali, > > > > > > > > On Thu, Apr 25, 2019 at 2:42 PM Luiz Augusto von Dentz > > > > wrote: > > > > > > > > > > Hi Pali, > > > > > > > > > > On Thu, Apr 25, 2019 at 2:35 PM Pali Rohár > > > > > wrote: > > > > > > > > > > > > On Thursday 25 April 2019 13:28:16 Pali Rohár wrote: > > > > > > > On Thursday 25 April 2019 14:19:15 Luiz Augusto von Dentz wrote: > > > > > > > > These seems to work great, I can even switch on the fly the > > > > > > > > profiles > > > > > > > > and after a short delay it switches without a problem, there is > > > > > > > > one > > > > > > > > issue related to reconnecting though: > > > > > > > > > > > > > > > > https://gist.github.com/Vudentz/40f10e85fb860083958edae67093f016 > > > > > > > > > > > > > > > > With BlueZ remembering the last used endpoint (aptX) it seems > > > > > > > > the > > > > > > > > policy ignores that and reverts to highest priority (SBC UHQ), > > > > > > > > > > > > Relevant lines: > > > > > > > > > > > > D: [lt-pulseaudio] bluez5-util.c: Transport > > > > > > /org/bluez/hci0/dev_94_20_53_2E_08_CE/sep5/fd26 available for > > > > > > profile a2dp_sink_aptx > > > > > > ... > > > > > > D: [lt-pulseaudio] card.c: a2dp_sink_aptx availability unknown > > > > > > ... > > > > > > D: [lt-pulseaudio] card.c: off availability yes > > > > > > I: [lt-pulseaudio] card.c: bluez_card.94_20_53_2E_08_CE: > > > > > > active_profile: a2dp_sink_sbc_uhq2 > > > > > > D: [lt-pulseaudio] module-bluetooth-policy.c: Looking for A2DP > > > > > > profile activated by bluez for card bluez_card.94_20_53_2E_08_CE > > > > > > I: [lt-pulseaudio] card.c: Created 5 "bluez_card.94_20_53_2E_08_CE" > > > > > > > > > > > > We got information that sep5 is activated with fd26 and it > > > > > > corespondent > > > > > > to profile a2dp_sink_aptx. And on next lines we see that profile has > > > > > > unknown availability -- which means that it is possible to switch to > > > > > > that codec/profile, but it is not activated yet. On next lines we > > > > > > see > > > > > > that module-bluetooth-policy is trying to find "a2dp_*" which has > > > > > > availability "on", but there is no one. So initial profile stay > > > > > > a2dp_sink_sbc_uhq2 which was chosen as default by card.c. > > > > > > > > > > > > So problem is why a2dp_sink_aptx profile has unknown availability > > > > > > even > > > > > > it is activated? It should have "on" availability. And then policy > > > > > > choose it as initial. > > > > > > > > > > Right, looks like the state is not correct since it has a fd already > > > > > it should have been marked available. > > > > > > > > Problem seems to be that we need to set the transport state to playing > > > > since we introduce the following code: > > > > > > > > if (cp->available == PA_AVAILABLE_NO && > > > > u->support_a2dp_codec_switch && pa_bluetooth_profile_is_a2dp(profile)) > > > > cp->available = PA_AVAILABLE_UNKNOWN; > > > > > > > > That means every A2DP profile will be set to unknown including even if > > > > they have no transport yet > > > > > > That is truth. But if there is a transport then availability is YES. > > > > > > Availability NO is used when it is not possible to activate transport > > > because it is unsupported (e.g. A2DP not connected or when bluez does > > > not support profile switching). > > > > > > > so now we have to set the initial transport to playing > > > > > > How it should help? I do not see reason now... > > > > > > Anyway, I was not able to reproduce your problem, basically I always had > > > availability for activated profile set to YES. > > > > Now I see it. PA_AVAILABLE_YES is returned only for > > PA_BLUETOOTH_TRANSPORT_STATE_PLAYING. > > > > So for PA_BLUETOOTH_TRANSPORT_STATE_IDLE we also get > > PA_AVAILABLE_UNKNOWN and therefore module-bluetooth-policy does not know > > which transport is activated. > > > > Cannot we get transport state in module-bluetooth-policy? Seems that > > this is the right direction. > > Currently we have following mapping: > > PA_BLUETOOTH_TRANSPORT_STATE_DISCONNECTED --> PA_AVAILABLE_NO > PA_BLUETOOTH_TRANSPORT_STATE_PLAYING --> PA_AVAILABLE_YES > PA_BLUETOOTH_TRANSPORT_STATE_IDLE --> PA_AVAILABLE_UNKNOWN > > Plus PA_AVAILABLE_NO is changed to PA_AVAILABLE_UNKNOWN when pulseaudio > can activate that transport via bluez codec switch API as described > above. > > PA_PORT_AVAILABLE_YES is defined as: > This port is available, likely because the jack is plugged in. > > PA_PORT_AVAILABLE_NO as: > This port is not available, likely because the jack is not plugged in. > > And PA_PORT_AVAILABLE_UNKNOWN as: > This port does not support jack detection > > Seems that PA code and applications skips profiles with PA_AVAILABLE_NO > and do not allow to
