Re: [pulseaudio-discuss] USB headset Steelseries Arctis troubleshooting

[Tanu Kaskinen]

On Thu, 2017-08-17 at 21:25 +0300, Johan Heikkilä wrote:
> 2017-08-17 14:05 GMT+03:00 Tanu Kaskinen :
> > Path files tell pulseaudio how to use the alsa mixer. If the sound card
> > provides hardware volume and mute controls in the alsa mixer, then it
> > would be good to write some path files, or if the mixer elements follow
> > a "standard" naming scheme, you can just reference the existing path
> > names from the mapping configuration.
> > 
> > The path files are used with both automatic and manual profiles.
> > 
> 
> OK, I guess there is no need for paths for the headphones. Volumes
> seem to work fine as it is.

You wrote in the first mail that you had to turn the volume up in
alsamixer. If we want to fix this for all users, that step should be
eliminated.

> > I don't know exactly what kind of logic the gnome ui uses when choosing
> > what profiles to show, but if you define an input path, the ui might
> > figure out that it doesn't need to show multiple profiles in the input
> > section, since there's really only one input available.
> > 
> 
> Do I have to write my own input path? I tried adding paths-input =
> analog-input-headset-mic, but it didn't make any difference.

Can you show the output of "amixer -c1"? Replace "1" with whatever
index alsa has assigned to the card (you can see the indexes in
/proc/asound/cards).

-- 
Tanu

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

Re: [pulseaudio-discuss] USB headset Steelseries Arctis troubleshooting

[Johan Heikkilä]

2017-08-17 14:05 GMT+03:00 Tanu Kaskinen :
>
> What do you mean by "the device is turned off"? That sounds strange.
>

Obviously selecting an input profile in the output view (and vice
versa) isn't supposed to work, so something gets confused and the
device disappears from Gnome sound settings and the Profile becomes
"Off" in pavucontrol configuration. I can select the correct profile
again in pavucontrol and the device is back.

> The priority determines which profile to choose by default, when the
> user hasn't explicitly chosen any particular profile.
>

Ok, that works fine.

>
> Path files tell pulseaudio how to use the alsa mixer. If the sound card
> provides hardware volume and mute controls in the alsa mixer, then it
> would be good to write some path files, or if the mixer elements follow
> a "standard" naming scheme, you can just reference the existing path
> names from the mapping configuration.
>
> The path files are used with both automatic and manual profiles.
>

OK, I guess there is no need for paths for the headphones. Volumes
seem to work fine as it is.

>
> I don't know exactly what kind of logic the gnome ui uses when choosing
> what profiles to show, but if you define an input path, the ui might
> figure out that it doesn't need to show multiple profiles in the input
> section, since there's really only one input available.
>

Do I have to write my own input path? I tried adding paths-input =
analog-input-headset-mic, but it didn't make any difference.

In the end there is no difference writing my own profiles. Now I just
set "auto-profiles = yes" and have the same amount of profiles that
seem to work fine (also the correct device has highest priority). And
in pavucontrol it looks fine.

But the problem is still that both input and output profiles are
listed both in inputs and outputs in Gnome settings and selecting a
wrong one switches profile to off.


--
Johan Heikkilä

GSM: +358 50 589 33 22
PGP fingerprint: 716B1611DAC9267CE40CF90D6BC286B9F0FA6FD3
PGP signature: https://keybase.io/johanh/pgp_keys.asc
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

[pulseaudio-discuss] [PATCH] main: set umask to 077 instead of 022

[Tanu Kaskinen]

It was reported that PulseAudio weakens the umask to 022 if it's
initially set to 077. That's not as big problem as it might seem,
but it's still a problem. The umask affects the permissions of the state
files, and those aren't readable by other users anyway in the per-user
mode, because PulseAudio puts them in directories that aren't
accessible to other users. In the system mode the state files will be
readable by everyone, though, even by those users that don't otherwise
have access to PulseAudio. The state files are slightly
privacy-sensitive, because they contain e.g. history of applications
that have used PulseAudio.

I can't think of any use cases where access to the state files by other
users would be necessary, either in the per-user mode or in the system
mode, so let's use umask 077. This doesn't prevent access to any
sockets in the system mode, because all directories that PulseAudio
creates in the system mode will have permissions 755 regardless of the
umask, and the sockets themselves always have permissions 777.

BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=102060
---
 src/daemon/main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/daemon/main.c b/src/daemon/main.c
index f35252d06..9d99b8fe2 100644
--- a/src/daemon/main.c
+++ b/src/daemon/main.c
@@ -888,7 +888,7 @@ int main(int argc, char *argv[]) {
 
 pa_set_env_and_record("PULSE_INTERNAL", "1");
 pa_assert_se(chdir("/") == 0);
-umask(0022);
+umask(0077);
 
 #ifdef HAVE_SYS_RESOURCE_H
 set_all_rlimits(conf);
-- 
2.13.2

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

Re: [pulseaudio-discuss] configuring pulseaudio as backend for Qemu

[Alexander E. Patrakov]

2017-08-17 17:20 GMT+05:00 Sameeh Jubran :
> Hi all,
>
> I am trying to set pulseaudio as a backend for qemu with intel hda virtual
> sound card. I can't seem to configure pulseaudio correctly due sudo
> privileges mismatch, I run Qemu with sudo but when I attempt to run
> pulseaudio with sudo I can't hear anything. Is there any detailed tutorial
> on how to accomplish this?

Why do you run qemu with sudo? This should not be needed. If this is
due to the graphics card pass-through, try to chown the vfio nodes to
your user instead.

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

Re: [pulseaudio-discuss] How to decode and loop-back and iec958/spdif bitstream?

[Denis Shulyaka]

Hi Benjamin,

*Sun Mar 8 11:22:30 PDT 2015* *Alexander E. Patrakov* 

:

> 08.03.2015 23:00, Benjamin Tegge wrote:
> >* Hello,
> *>>* I want to feed a 5.1 stream (dca or a52) from another device through a
> *>* iec958/spdif connection to my computer and play the audio through
> *>* loopback on the computer, I don't want to do pass-through. The C-Media
> *>* CM106-based device used with PulseAudio and the loopback module on
> *>* Ubuntu 14.04 (PulseAudio 4.0) work in stereo, but 5.1 does not.
> *>>* I wanted to set this up for quite some time, but was puzzled how all the
> *>* parts come together:
> *>* - There is iecset from the alsa tools to configure iec958 ports
> *>* (audio/data, consumer/pro), but this is just for outgoing connections,
> *>* right?
> *>* - Are there decoding functions in PulseAudio or would I have to use an
> *>* external program like ffmpeg/avconv to demux and decode the spdif
> *>* bitstream to PCM? I already found
> *>* https://www.ffmpeg.org/ffmpeg-devices.html#pulse 
>  and tried that, but
> *>* couldn't get 5.1 to work.
> *>
> PulseAudio contains no decoders, so you would need to use an external
> tool. Also, PulseAudio does not support receiving compressed formats
> over spdif. Possibly this pipeline could work as a proof of concept:
>
> arecord -f dat -D spdif:1 | ffmpeg -f spdif -i - -f pulse default
>
> or:
>
> ffmpeg -f alsa -acodec ac3 -i spdif:1 -f pulse default
>
> (not tested, because I don't have anything with spdif-input capability)
>
> --
> Alexander E. Patrakov
>
>
Were you able to make it work?

I'm trying to do the same thing now, but it looks like CM106 does not allow
me to record a compressed format and I get a complete silence instead. I
even wrote a small app to do the decoding (
https://github.com/Shulyaka/pareceive) which does not work because of this
fact.

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

[pulseaudio-discuss] configuring pulseaudio as backend for Qemu

[Sameeh Jubran]

Hi all,

I am trying to set pulseaudio as a backend for qemu with intel hda virtual
sound card. I can't seem to configure pulseaudio correctly due sudo
privileges mismatch, I run Qemu with sudo but when I attempt to run
pulseaudio with sudo I can't hear anything. Is there any detailed tutorial
on how to accomplish this?

I am getting this error in Qemu:

*pulseaudio: pa_context_connect() failed*
*pulseaudio: Reason: Connection refused*
*pulseaudio: Failed to initialize PA contextaudio: Could not init `pa'
audio driver*
*pulseaudio: pa_context_connect() failed*


Some things to note:

* I am no using libvirt and I don't want to use it :)
* I am running fedora 25/26 as a host
* The guest is Windows 10


Thanks in advance =)
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] USB headset Steelseries Arctis troubleshooting

[Tanu Kaskinen]

On Tue, 2017-08-15 at 19:42 +0300, Johan Heikkilä wrote:
> I'm trying to get my head around the profile concept in pulse.
> 
> I made an udev row pointing at the following mapping:
> 
> /usr/share/pulseaudio/alsa-mixer/profile-sets/steelseries-arctis-usb-audio.conf
> 
> [Mapping analog-mono]
> description = Analog Mono Headphone
> device-strings = hw:%f,0,0
> channel-map = mono
> direction = output
> 
> [Mapping analog-stereo]
> description = Analog Stereo Headphone
> device-strings = hw:%f,1,0
> channel-map = left,right
> direction = output
> 
> [Mapping analog-input-headset-mic]
> description = Headset Microphone
> device-strings = hw:%f,0,0
> channel-map = mono
> direction = input
> 
> If I set "auto-profiles = yes" I get a bunch of profiles that are
> listed in Gnome sound settings both in Output and Input. Selecting an
> Output profile in the Input dialog and the other way around makes
> things very messy and the device is turned off and has to be selected
> again in pavucontrol configuration.

What do you mean by "the device is turned off"? That sounds strange.

> When instead disabling auto-profiles and creating the following
> profiles in the file, it looks correct in Output (stereo and mono
> device listed), but in Input also Stereo output and Mono output is
> listed besides the mic input (which makes things messy again if they
> are selected).
> 
> [Profile output:analog-mono]
> description = Analog mono output
> output-mappings = analog-mono
> priority = 60
> skip-probe = yes
> 
> [Profile output:analog-stereo]
> description = Analog stereo output
> output-mappings = analog-stereo
> priority = 65
> skip-probe = yes
> 
> [Profile output:analog-mono+input:analog-input-headset-mic]
> description = Analog mono output + Analog mono input
> output-mappings = analog-mono
> input-mappings = analog-input-headset-mic
> priority = 75
> skip-probe = yes
> 
> [Profile output:analog-stereo+input:analog-input-headset-mic]
> description = Analog stereo output + Analog mono input
> output-mappings = analog-stereo
> input-mappings = analog-input-headset-mic
> priority = 80
> skip-probe = yes
> 
> 
> I have no idea how the priority works, btw.

The priority determines which profile to choose by default, when the
user hasn't explicitly chosen any particular profile.

> And I'm completely missing
> the point of the separate paths files (are they used with
> auto-profiles?).

Path files tell pulseaudio how to use the alsa mixer. If the sound card
provides hardware volume and mute controls in the alsa mixer, then it
would be good to write some path files, or if the mixer elements follow
a "standard" naming scheme, you can just reference the existing path
names from the mapping configuration.

The path files are used with both automatic and manual profiles.

> So the real question is, how can I prevent any other profiles from
> being listed under Input in Gnome sound settings?

I don't know exactly what kind of logic the gnome ui uses when choosing
what profiles to show, but if you define an input path, the ui might
figure out that it doesn't need to show multiple profiles in the input
section, since there's really only one input available.

-- 
Tanu

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

Re: [pulseaudio-discuss] PulseAudio is unable to detect right profile on this system.

[Tanu Kaskinen]

On Mon, 2017-08-14 at 11:24 +0430, Farhad Mohammadi Majd wrote:
> Hello, unlike the past, I don't want/can't to install additonal
> graphical software to configure PulseAudio to work correctly, so please
> help me.
> 
> system:
> 
> Fedora 26 work station, GNOME 3.24

So you're still using a graphical environment (gnome), but you can't
install additional software? Is this the same hardware as what you had
before, or some new hardware that isn't working properly?

The email subject says "unable to detect right profile". What is the
right profile? What does "pactl list cards" print?

-- 
Tanu

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

Re: [pulseaudio-discuss] [PATCH 2/2] loopback: Track and use average adjust time

[Tanu Kaskinen]

On Sun, 2017-08-13 at 13:00 +0200, Georg Chini wrote:
> On 04.08.2017 15:37, Tanu Kaskinen wrote:
> > On Mon, 2017-04-17 at 21:37 +0200, Georg Chini wrote:
> > > @@ -327,11 +335,20 @@ static void adjust_rates(struct userdata *u) {
> > >   }
> > >   
> > >   /* Allow one underrun per hour */
> > > -if (u->iteration_counter * u->adjust_time / PA_USEC_PER_SEC / 3600 > 
> > > run_hours) {
> > > +if (u->iteration_counter * u->real_adjust_time / PA_USEC_PER_SEC / 
> > > 3600 > run_hours) {
> > >   u->underrun_counter = PA_CLIP_SUB(u->underrun_counter, 1u);
> > >   pa_log_info("Underrun counter: %u", u->underrun_counter);
> > >   }
> > >   
> > > +/* Calculate real adjust time */
> > > +now = pa_rtclock_now();
> > > +if (!u->source_sink_changed) {
> > > +u->adjust_counter++;
> > > +u->real_adjust_time_sum += now - u->adjust_time_stamp;
> > > +u->real_adjust_time = u->real_adjust_time_sum / 
> > > u->adjust_counter;
> > > +}
> > > +u->adjust_time_stamp = now;
> > > +
> > >   /* Rates and latencies*/
> > >   old_rate = u->sink_input->sample_spec.rate;
> > >   base_rate = u->source_output->sample_spec.rate;
> > > @@ -364,7 +381,9 @@ static void adjust_rates(struct userdata *u) {
> > >   pa_log_debug("Loopback latency at base rate is %0.2f ms", 
> > > (double)latency_at_optimum_rate / PA_USEC_PER_MSEC);
> > >   
> > >   /* Calculate new rate */
> > > -new_rate = rate_controller(base_rate, u->adjust_time, 
> > > latency_difference);
> > > +new_rate = rate_controller(base_rate, u->real_adjust_time, 
> > > latency_difference);
> > > +
> > > +u->source_sink_changed = false;
> > 
> > This "source_sink_changed = false" assignment would be better right
> > after the code that checks its value, at least based on this patch
> > alone. But maybe later patches use this variable too in a way that
> > makes this suggestion less good?
> > 
> > Otherwise looks fine.
> > 
> 
> Yes, the variable is later user within rate_controller(). Also there will be
> other variables that indicate state changes between two calls of
> adjust_rate() (for example if the latency offset changed). I'll push the 
> patch
> to next as is if you have no objection.

Go ahead, no objections.

-- 
Tanu

https://www.patreon.com/tanuk
___
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 loopback or combine-sink

[Tanu Kaskinen]

On Thu, 2017-08-17 at 08:30 +0200, Georg Chini wrote:
> On 17.08.2017 07:53, Tanu Kaskinen wrote:
> > On Sat, 2017-08-12 at 22:29 +0200, Georg Chini wrote:
> > > Currently pulseaudio crashes with an assertion in 
> > > pa_rtpoll_item_new_asyncmsgq_read()
> > > or pa_rtpoll_item_new_asyncmsgq_write() if a loopback is applied to a 
> > > tunnel-new
> > > sink or source, because tunnel-{sink,source}-new do not set 
> > > thread_info.rtpoll.
> > > The same applies to module-combine-sink and module-rtp-recv.
> > > 
> > > This patch is not a complete fix for the problem but provides a temporary 
> > > band-aid
> > > by initializing thread_info.rtpoll properly. The rtpoll created is never 
> > > run, but
> > > loopback and combine-sink nevertheless work, see comments in the code.
> > > 
> > > This patch does not work for module-rtp-recv, but using rtp-recv with a 
> > > remote
> > > sink does not seem to make a lot of sense anyway.
> > > 
> > > Bug link: https://bugs.freedesktop.org/show_bug.cgi?id=73429
> > > ---
> > >   src/modules/module-tunnel-sink-new.c   | 15 +++
> > >   src/modules/module-tunnel-source-new.c | 12 
> > >   2 files changed, 27 insertions(+)
> > 
> > Thanks! Pushed to next.
> > 
> 
> Should it not go to master as well because it fixes a crash?

Yes, you're right. It's now in master too.

-- 
Tanu

https://www.patreon.com/tanuk
___
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 loopback or combine-sink

[Georg Chini]

On 17.08.2017 07:53, Tanu Kaskinen wrote:

On Sat, 2017-08-12 at 22:29 +0200, Georg Chini wrote:

Currently pulseaudio crashes with an assertion in 
pa_rtpoll_item_new_asyncmsgq_read()
or pa_rtpoll_item_new_asyncmsgq_write() if a loopback is applied to a tunnel-new
sink or source, because tunnel-{sink,source}-new do not set thread_info.rtpoll.
The same applies to module-combine-sink and module-rtp-recv.

This patch is not a complete fix for the problem but provides a temporary 
band-aid
by initializing thread_info.rtpoll properly. The rtpoll created is never run, 
but
loopback and combine-sink nevertheless work, see comments in the code.

This patch does not work for module-rtp-recv, but using rtp-recv with a remote
sink does not seem to make a lot of sense anyway.

Bug link: https://bugs.freedesktop.org/show_bug.cgi?id=73429
---
  src/modules/module-tunnel-sink-new.c   | 15 +++
  src/modules/module-tunnel-source-new.c | 12 
  2 files changed, 27 insertions(+)

Thanks! Pushed to next.


Should it not go to master as well because it fixes a crash?

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