[pulseaudio-discuss] PulseAudio Network Sink: Respect alternative sample rate and format

[Maximilian Böhm]

Hello, I’m very happy that I finally got PulseAudio’s awesome network sink 
feature set up. Works so far, but the AV receiver on the other computer tells 
me it gets 41,1 kHz whereas my input in the sink from my client computer is 48 
kHz (movies).
On both computers, the /etc/pulse/daemon.conf is configured like so:

default-sample-format = s24le
default-sample-rate = 44100
alternate-sample-rate = 48000

If I set the default sample rate to 48 kHz on the server, the AV receiver gets 
48 kHz as well. But I’m afraid my client could still be sending a resampled 
41,1 kHz signal to the server. Also, no idea if the 24-bit format is preserved 
or cut to 16-bit (I play a lot video tracks in 24-bit).
My preferred setup would be one in which the server switches from 48 kHz to 
41,1 kHz dependent on how it gets input, like a desktop. BTW, this works 
flawlessly over a direct S/PDIF connection from my computers to the AV receiver.
I can’t find any documentation on this. Would appreciate your help.
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Decode SPDIF compressed formats

[Denis Shulyaka]

2017-07-20 17:06 GMT+02:00 Tanu Kaskinen :

> No, I don't think there's currently any code to read the status bits
> from the alsa mixer.
>

But in general, if one wants to passthrow unmodified uncompressed PCM data
from S/PDIF-in to HDMI, shouldn't he know the source sample rate to
correctly open the output device?
Do I understand it correct that the only way to implement this scenario
with PA is to indirrectly measure the sample rate by comparing the
pa_bytes_to_usec() result against the actual time passed?
If the source is opened with 48000 sample rate, but produces the data at
44100 rate, will I receive a buffer underflow error on the source?

Best regards,
Denis Shulyaka
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH 3/4] pactl, pacmd, cli-command: Add send-message command

[Peter Meerwald-Stadler]

some minor comments below

> ---
>  man/pactl.1.xml.in   |  6 ++
>  man/pulse-cli-syntax.5.xml.in|  6 ++
>  shell-completion/bash/pulseaudio |  5 +++--
>  shell-completion/zsh/_pulseaudio |  2 ++
>  src/pulsecore/cli-command.c  | 44 
> 
>  src/utils/pacmd.c|  1 +
>  src/utils/pactl.c| 39 ++-
>  7 files changed, 100 insertions(+), 3 deletions(-)
> 
> diff --git a/man/pactl.1.xml.in b/man/pactl.1.xml.in
> index 39569b6b..e868babc 100644
> --- a/man/pactl.1.xml.in
> +++ b/man/pactl.1.xml.in
> @@ -246,6 +246,12 @@ License along with PulseAudio; if not, see 
> .
> 
>  
>  
> +  send-message RECIPIENT MESSAGE 
> MESSAGE_PARAMETERS
> +  Send a message string to the specified recipient object. 
> If applicable an additional string containing
> +  message parameters can be specified. A string is returned as a 
> response to the message.
> +
> +
> +
>subscribe
>Subscribe to events, pactl does not exit by itself, but 
> keeps waiting for new events.
>  
> diff --git a/man/pulse-cli-syntax.5.xml.in b/man/pulse-cli-syntax.5.xml.in
> index 0a0fabaf..adf33f58 100644
> --- a/man/pulse-cli-syntax.5.xml.in
> +++ b/man/pulse-cli-syntax.5.xml.in
> @@ -298,6 +298,12 @@ License along with PulseAudio; if not, see 
> .
>  
>  
>  
> +  send-message recipient message 
> message_parameters
> +  Send a message string to the specified recipient object. 
> If applicable an additional string containing
> +  message parameters can be specified. A string is returned as a 
> response to the message.
> +
> +
> +
>exit
>Terminate the daemon. If you want to terminate a CLI
>connection ("log out") you might want to use ctrl+d
> diff --git a/shell-completion/bash/pulseaudio 
> b/shell-completion/bash/pulseaudio
> index e473b9c2..ac02afac 100644
> --- a/shell-completion/bash/pulseaudio
> +++ b/shell-completion/bash/pulseaudio
> @@ -120,7 +120,8 @@ _pactl() {
>  set-source-port set-sink-volume set-source-volume
>  set-sink-input-volume set-source-output-volume 
> set-sink-mute
>  set-source-mute set-sink-input-mute 
> set-source-output-mute
> -set-sink-formats set-port-latency-offset subscribe help)
> +set-sink-formats set-port-latency-offset send-message 
> subscribe
> +help)
>  
>  _init_completion -n = || return
>  preprev=${words[$cword-2]}
> @@ -270,7 +271,7 @@ _pacmd() {
>  move-sink-input move-source-output suspend-sink 
> suspend-source
>  suspend set-card-profile set-sink-port set-source-port
>  set-port-latency-offset set-log-target set-log-level 
> set-log-meta
> -set-log-time set-log-backtrace)
> +set-log-time set-log-backtrace send-message)
>  _init_completion -n = || return
>  preprev=${words[$cword-2]}
>  
> diff --git a/shell-completion/zsh/_pulseaudio 
> b/shell-completion/zsh/_pulseaudio
> index 0e9e89bd..a2817ebb 100644
> --- a/shell-completion/zsh/_pulseaudio
> +++ b/shell-completion/zsh/_pulseaudio
> @@ -263,6 +263,7 @@ _pactl_completion() {
>  'set-sink-input-mute: mute a stream'
>  'set-source-output-mute: mute a recording stream'
>  'set-sink-formats: set supported formats of a sink'
> +'send-message: send a message to a pulseaudio object'

the canonical spelling is PulseAudio I think (here and below)

>  'subscribe: subscribe to events'
>  )
>  
> @@ -561,6 +562,7 @@ _pacmd_completion() {
>  'dump: show daemon configuration'
>  'dump-volumes: show the state of all volumes'
>  'shared: show shared properties'
> +'send-message: send a message to a pulseaudio object'
>  'exit: ask the PulseAudio daemon to exit'
>  )
>  _describe 'pacmd commands' _pacmd_commands
> diff --git a/src/pulsecore/cli-command.c b/src/pulsecore/cli-command.c
> index 01fea475..598cef44 100644
> --- a/src/pulsecore/cli-command.c
> +++ b/src/pulsecore/cli-command.c
> @@ -135,6 +135,7 @@ static int pa_cli_command_sink_port(pa_core *c, 
> pa_tokenizer *t, pa_strbuf *buf,
>  static int pa_cli_command_source_port(pa_core *c, pa_tokenizer *t, pa_strbuf 
> *buf, bool *fail);
>  static int pa_cli_command_port_offset(pa_core *c, pa_tokenizer *t, pa_strbuf 
> *buf, bool *fail);
>  static int pa_cli_command_dump_volumes(pa_core *c, pa_tokenizer *t, 
> pa_strbuf *buf, bool *fail);
> +static int pa_cli_command_send_message_to_object(pa_core *c, pa_tokenizer 
> *t, pa_strbuf *buf, bool *fail);
>  
>  /* A method table for all available commands */
>  
> @@ -191,6 +192,7 @@ static const struct command 

Re: [pulseaudio-discuss] [RAOP] [PATCH] Fix audio synchronisation

[Colin Leroy]

On 22 July 2017 at 14h53, Colin Leroy wrote:

Hi, 

> I think I've figured out how to cleanly synchronise audio and video
> with RAOP with relying on my empirical "shifting audio 2300ms in
> mplayer works".

*without*relying on, obviously :)

-- 
Colin


pgpXjMhc_qoTC.pgp
Description: OpenPGP digital signature
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] User-hostile obfuscation in PulseAudio Volume Control is a real pain.

[Georg Chini]

On 22.07.2017 11:59, Georg Chini wrote:

On 22.07.2017 11:37, Erik Christiansen wrote:

Hi,

Debian 9.0.0 comes with pulseaudio 10.0, so it's not likely that fixes
for the problem are in the wild yet, I figure.

Even when a Debian 9.0.0 box is connected to a HDMI monitor, PulseAudio
Volume Control displays only 3 of its 5 tabs, supressing the vital
Configuration tab, needed for switching audio output to HDMI. Depriving
the user of knowledge of the availability of the Configuration tab, by
burying it under two levels of blind hammering on a tiny inscrutable
icon in the corner is a monstrous disservice to the user, and a rather
weird design decision. Much space is wasted in the width of the 3
displayed tabs, and on many a screen there is at least half a yard of
screen width spare for the other 2 tabs.
discuss


Hi Erik,

I don't really understand. Are you talking about pavucontrol when
you are saying "PulseAudio Volume Control"?
As far as I know, pavucontol always displays 5 tabs, the configuration
is one of them and there is no option to suppress any of the tabs.

If this is different in your distribution or you are not talking about
pavucontrol, the pulseaudio mailing list is the wrong place to complain.
You have to go back to the maintainers of your distribution. (Although
I am running Debian unstable and pavucontrol there displays all 5 tabs,
so I understand your complain even less.)

Regards
 Georg


(There is a "t" missing above ...)

I've just seen there is a pavucontrol-qt package. Maybe you are using that.

From https://github.com/lxde/pavucontrol-qt:

"The software belongs to the LXQt project but its usage isn't limited to 
this desktop environment."


So you may have to ask them to change the behavior.

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

Re: [pulseaudio-discuss] User-hostile obfuscation in PulseAudio Volume Control is a real pain.

[Georg Chini]

On 22.07.2017 11:37, Erik Christiansen wrote:

Hi,

Debian 9.0.0 comes with pulseaudio 10.0, so it's not likely that fixes
for the problem are in the wild yet, I figure.

Even when a Debian 9.0.0 box is connected to a HDMI monitor, PulseAudio
Volume Control displays only 3 of its 5 tabs, supressing the vital
Configuration tab, needed for switching audio output to HDMI. Depriving
the user of knowledge of the availability of the Configuration tab, by
burying it under two levels of blind hammering on a tiny inscrutable
icon in the corner is a monstrous disservice to the user, and a rather
weird design decision. Much space is wasted in the width of the 3
displayed tabs, and on many a screen there is at least half a yard of
screen width spare for the other 2 tabs.
discuss


Hi Erik,

I don't really understand. Are you talking about pavucontrol when
you are saying "PulseAudio Volume Control"?
As far as I know, pavucontol always displays 5 tabs, the configuration
is one of them and there is no option to suppress any of the tabs.

If this is different in your distribution or you are not talking about
pavucontrol, the pulseaudio mailing list is the wrong place to complain.
You have to go back to the maintainers of your distribution. (Although
I am running Debian unstable and pavucontrol there displays all 5 tabs,
so I understand your complain even less.)

Regards
 Georg

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

[pulseaudio-discuss] User-hostile obfuscation in PulseAudio Volume Control is a real pain.

[Erik Christiansen]

Hi,

Debian 9.0.0 comes with pulseaudio 10.0, so it's not likely that fixes
for the problem are in the wild yet, I figure.

Even when a Debian 9.0.0 box is connected to a HDMI monitor, PulseAudio
Volume Control displays only 3 of its 5 tabs, supressing the vital
Configuration tab, needed for switching audio output to HDMI. Depriving
the user of knowledge of the availability of the Configuration tab, by
burying it under two levels of blind hammering on a tiny inscrutable
icon in the corner is a monstrous disservice to the user, and a rather
weird design decision. Much space is wasted in the width of the 3
displayed tabs, and on many a screen there is at least half a yard of
screen width spare for the other 2 tabs.

I've now cracked the secret code, but enquiries on other lists elicited
no-one else who had. I'm merely a little myopic - others have far less
acute eyesight with which to recognise the triangular flyspecks. I
understand that a GUI is a device to put facilities at the end of long
maze runs, but seriously, TWO levels of blind wall punching at the end
of that, to dig out access to the unnecessarily hidden function?

If all 5 tabs were to be displayed, then it would be a service to users,
and a sign that the pulseaudio design takes usability into account in
the design process.

Please understand that users do not know that the control is secreted in
an obfuscated PulseAudio Volume Control, and so end up scouring all
interfaces, GUI and command-line, plus the internet, in the process of
discovery. Your power to waste humanity's time is significant.

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

Re: [pulseaudio-discuss] [PATCH] tunnel-{sink, source}-new: Fix assertion when used with module-loopback

[Georg Chini]

On 20.07.2017 15:48, Tanu Kaskinen wrote:

On Mon, 2017-07-17 at 19:53 +0200, Georg Chini wrote:

On 17.07.2017 19:32, Tanu Kaskinen wrote:

On Sun, 2017-07-16 at 11:42 +0200, Georg Chini wrote:

Currently pulseaudio crashes with an assertion in 
pa_rtpoll_item_new_asyncmsgq_read()
if a loopback is applied to a tunnel-new sink/source because 
tunnel-{sink,source}-new
do not set thread_info.rtpoll. Bug was reported on IRC.

This patch fixes the problem by initializing thread_info.rtpoll properly.

Did you test this patch? The tunnel devices don't run the rtpoll that
you create, so I would expect that the loopback won't work.

This is a known bug that I started working on in the past:
https://bugs.freedesktop.org/show_bug.cgi?id=73429

I made some patches, issues got pointed out in review, and then I never
finished v2 of the patches. I haven't given up on that, but it's been a
year since I last worked on it... In case you're interested in the
current state of the v2 patches, I pushed the code to
git://people.freedesktop.org/~tanuk/pulseaudio branch "rtpoll-mainloop-
v2".


I haven't tested it myself, but the bug reporter on IRC (tar-dingens)
tested them and said it worked. The patch looked like the easiest way to
make module-loopback happy.

I don't understand how it can work. module-loopback uses the rtpoll to
set up the internal asyncmsgq. If the tunnel device doesn't run the
rtpoll, the messages shouldn't get processed. One of the messages is
used to send memchunks from the source to the sink, so there should be
no audio moving if the messages aren't processed.


I think I know why it works. The messages are processed in
sink_input_pop_cb(). module-loopback calls
pa_asyncmsgq_process_one() from there. So it is not necessary
to run the rtpoll at all. From what I know about the loopback code
it should be fine this way.
The question is, if we can hit other issues with the "fake" rtpoll.
If not, I think we could generally go with the patch (and add some
comments in the tunnel modules that the rtpoll is not used at all
and only there to make module-loopback happy).

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