Re: [pulseaudio-discuss] [PATCH] alsa: make headset-mic scanned earlier than headphone-mic
On 05/20/2017 10:51 PM, Tanu Kaskinen wrote: On Fri, 2017-05-19 at 09:29 +0800, Hui Wang wrote: Hello Tanu, Could you please help take a look at this patch? This patch really fix an issue on some Dell machines (with realtek codec and has no internal microphone on them), And I think this minor change will not introduce regression, it is pretty safe. The patch only changes the order in which headset-mic and headphone-mic are listed, and that order should not have any real impact on anything. There's clearly a bug somewhere, but the bug can't be that the paths are listed in the wrong order, since the order should not matter. Yes, you are right. In theory, the headset-mic and headphone-mic have the same priority, so exchanging their order should not have any real impact on anything. But in practice, this bug exposes that in some situation( when there are only headphone-mic and headset-mic, and neither of them is plugged in.), the headphone-mic is not suitable to be the default active_port. So do you think if it is acceptable that I don't exchange their order, I just adjust their priorities to make the headset-mic's priority a bit higher than headphone-mic's? If the port must not be headphone-mic when the user chooses headphones in the UI, couldn't the UI program tell pulseaudio to switch to headset-mic? Yes, the UI program could do that. If it is not allowed to adjust their priorities, we have to change the UI program. Thanks, Hui. ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Detecting when data source disappears?
Sorry about reposting. I botched up the subject line, messing up the threading. I've been reading up and experimenting on both the simple and async APIs. In one experiment, I used a CLI file that sets up a set of module-sine modules with output remapped by module-remap-sink modules to a stream fed to a module-null-sink module. Could you please include the command sequence you are using? Maybe I can reproduce the problem here. I've attached the CLI file and the shell script I use to run it. The sequence is: ./restart-pulse.sh dist/data/sine-2x6.pa parec --device="test_sink0.monitor" --format=ulaw --rate=8000 --channels=6 --channel-map="aux0,aux1,aux2,aux3,aux4,aux5" parec0.raw Wait 10 seconds, then in another terminal: pactl unload-module module-remap-sink # or pactl unload-module module-sine Wait another 10 seconds, then kill parec with ctrl-c. I then look at parec0.raw by importing it in audacity (u-law, 6channels, 8000 smp/sec). I then wrote 2 programs, one using the simple API and the other the async API to read date from the module-null-sink monitor source and write the data to file (both based on examples to provide "parec" functionality). Then I could unload either all the module-sine modules or all the module-remap-sink modules to interrupt the data source to the module-null-sink module. Both programs gave the same result, which I don't completely understand. The issues I've found are: 1. After the data source is gone, the program continues to write data to file. There doesn't seem to be any way to detect a stream of "zero" data using the APIs. That is expected behavior. null-sink.monitor is not different from other sources, which means if there is no input to the null-sink, it will generate silence. It's like recording from an unplugged mic or line-in input. And there's no silence detection? No, there isn't. This would have to be implemented on application level. 2. If I run it for 20 seconds, with 10 seconds of sinusoidal data followed by 10 seconds of null data, the file ends up with anything from 30 to 40 seconds worth of data in it. 3. The files written from case 2, above, show the initial sinusoidal data as expected, but then, following data stream interruption, about 5 to 10 seconds of switching back and forth between segments of sinusoidal data and null data, before finally settling to null data only till the end of file. Did you test if the same happens with parec? If yes, are there any log messages during the time? Just did it and the result is the same. Attached is the relevant part of the syslog. This looks like a bug but the log is not verbose enough. The best way to get more information is to run pulseaudio with debugging enabled. You might need to disable autospawn in client.conf or stop the user service when using systemd before you can do so. Then run pulseaudio - from the command line. Will do. sine-2x6.pa load-module module-null-sink sink_name=test_sink0 sink_properties=device.description=test0 format=ulaw rate=8000 channels=6 channel_map=aux0,aux1,aux2,aux3,aux4,aux5 load-module module-null-sink sink_name=test_sink1 sink_properties=device.description=test1 format=ulaw rate=8000 channels=6 channel_map=aux0,aux1,aux2,aux3,aux4,aux5 load-module module-remap-sink sink_name=remap_sink0 master=test_sink0 sink_properties=device.description=test_remap0 format=ulaw rate=8000 channels=1 master_channel_map=aux0 remix=no load-module module-remap-sink sink_name=remap_sink1 master=test_sink1 sink_properties=device.description=test_remap1 format=ulaw rate=8000 channels=1 master_channel_map=aux0 remix=no load-module module-remap-sink sink_name=remap_sink2 master=test_sink0 sink_properties=device.description=test_remap2 format=ulaw rate=8000 channels=1 master_channel_map=aux1 remix=no load-module module-remap-sink sink_name=remap_sink3 master=test_sink1 sink_properties=device.description=test_remap3 format=ulaw rate=8000 channels=1 master_channel_map=aux1 remix=no load-module module-remap-sink sink_name=remap_sink4 master=test_sink0 sink_properties=device.description=test_remap4 format=ulaw rate=8000 channels=1 master_channel_map=aux2 remix=no load-module module-remap-sink sink_name=remap_sink5 master=test_sink1 sink_properties=device.description=test_remap5 format=ulaw rate=8000 channels=1 master_channel_map=aux2 remix=no load-module module-remap-sink sink_name=remap_sink6 master=test_sink0 sink_properties=device.description=test_remap6 format=ulaw rate=8000 channels=1 master_channel_map=aux3 remix=no load-module module-remap-sink sink_name=remap_sink7 master=test_sink1 sink_properties=device.description=test_remap7 format=ulaw rate=8000 channels=1 master_channel_map=aux3 remix=no load-module module-remap-sink sink_name=remap_sink8 master=test_sink0 sink_properties=device.description=test_remap8 format=ulaw rate=8000 channels=1 master_channel_map=aux4 remix=no load-module module-remap-sink sink_name
Re: [pulseaudio-discuss] Service fails on systemctl start. Status always "activating"
Ah! Sure enough, I had this line in my pulseaudio.service file: Requires=pulseaudio.socket I copied this file directly from the Debian source: https://sources.debian.net/src/pulseaudio/8.0-2/src/daemon/systemd/user/pulseaudio.service.in/ Debian trunk must be using a newer version of Pulseaudio than Raspbian. It looks like the latest version of Pulseaudio is 10.0. Do you know why Raspbian is still using 5.0? This is very interesting! I didn't know that: "Raspbian disables autospawning at every boot by overwriting ~/.config/pulse/client.conf" I actually had tried setting "autospawn=yes" in /etc/pulse/client.conf (isn't this the master version of client.conf?), but that seems to have no effect. I also don't know how to disable the overwriting of ~/.config/pulse/client.conf. So, now pulseaudio starts at boot, which is fantastic, thank you! Alas, I am still having a problem. Here's my .service file to start my script. # # foo.service [Unit] Description=Foo Requires=pulseaudio.service After=network.target pulseaudio.service [Service] Type=simple ExecStart=/home/pi/foo Restart=on-failure [Install] WantedBy=default.target # If I start it from the command line, it works just fine, but if I enable it to run at boot, it doesn't work, and in the logs I see this: ALSA lib pulse.c:243:(pulse_connect) PulseAudio: Unable to connect: Connection refused Any ideas? Maybe a timing issue with the ALSA plugin to interface with Pulseaudio? > On May 22, 2017, at 1:30 PM, Tanu Kaskinen wrote: > > On Mon, 2017-05-22 at 13:01 -0700, Karl Stahl wrote: >> Apparently the "xcb_connection_has_error()" message is caused by my >> having SSHed to the device. If I run the same command on the device >> directly, I don't get that message. My environment already had that >> variable set as you suggested: >> >> $ echo $XDG_RUNTIME_DIR >> /run/user/1000 >> >> In any case, I still get the "pa_context_connect() failed" message. >> >> Is pulseaudio running? Yes: >> $ ps -ef | grep pulse >> pi1050 809 0 11:14 ?00:00:54 /usr/bin/pulseaudio >> --daemonize=no >> >> $ PULSE_LOG=99 pactl info >> xcb_connection_has_error() returned true >> Using shared memory pool with 1024 slots of size 64.0 KiB each, total size >> is 64.0 MiB, maximum usable slot size is 65496 >> Trying to connect to /run/user/1000/pulse/native... >> connect(): Resource temporarily unavailable (11) > > This is the problem. The socket exists, but connecting to it fails. Are > you perhaps trying to use socket activation? In that case systemd > creates the socket, but pulseaudio doesn't use it, because 5.0 doesn't > support socket activation. Removing the .socket file should do the > trick. > > Why are you trying to use systemd to manage the user instance, by the > way? The old autospawning mechanism should work fine for automatically > starting pulseaudio on demand. Raspbian disables autospawning at every > boot by overwriting ~/.config/pulse/client.conf, though, so maybe > that's why you're trying this alternative method... In that case, I > would try to find what overwrites client.conf and disable that thing. > > -- > Tanu > > https://www.patreon.com/tanuk > ___ > 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] Service fails on systemctl start. Status always "activating"
On Mon, 2017-05-22 at 13:01 -0700, Karl Stahl wrote: > Apparently the "xcb_connection_has_error()" message is caused by my > having SSHed to the device. If I run the same command on the device > directly, I don't get that message. My environment already had that > variable set as you suggested: > > $ echo $XDG_RUNTIME_DIR > /run/user/1000 > > In any case, I still get the "pa_context_connect() failed" message. > > Is pulseaudio running? Yes: > $ ps -ef | grep pulse > pi1050 809 0 11:14 ?00:00:54 /usr/bin/pulseaudio > --daemonize=no > > $ PULSE_LOG=99 pactl info > xcb_connection_has_error() returned true > Using shared memory pool with 1024 slots of size 64.0 KiB each, total size is > 64.0 MiB, maximum usable slot size is 65496 > Trying to connect to /run/user/1000/pulse/native... > connect(): Resource temporarily unavailable (11) This is the problem. The socket exists, but connecting to it fails. Are you perhaps trying to use socket activation? In that case systemd creates the socket, but pulseaudio doesn't use it, because 5.0 doesn't support socket activation. Removing the .socket file should do the trick. Why are you trying to use systemd to manage the user instance, by the way? The old autospawning mechanism should work fine for automatically starting pulseaudio on demand. Raspbian disables autospawning at every boot by overwriting ~/.config/pulse/client.conf, though, so maybe that's why you're trying this alternative method... In that case, I would try to find what overwrites client.conf and disable that thing. -- 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] Service fails on systemctl start. Status always "activating"
Apparently the "xcb_connection_has_error()" message is caused by my having SSHed to the device. If I run the same command on the device directly, I don't get that message. My environment already had that variable set as you suggested: $ echo $XDG_RUNTIME_DIR /run/user/1000 In any case, I still get the "pa_context_connect() failed" message. Is pulseaudio running? Yes: $ ps -ef | grep pulse pi1050 809 0 11:14 ?00:00:54 /usr/bin/pulseaudio --daemonize=no $ PULSE_LOG=99 pactl info xcb_connection_has_error() returned true Using shared memory pool with 1024 slots of size 64.0 KiB each, total size is 64.0 MiB, maximum usable slot size is 65496 Trying to connect to /run/user/1000/pulse/native... connect(): Resource temporarily unavailable (11) Trying to connect to /var/run/pulse/native... connect(): No such file or directory (2) Connection failure: Connection refused pa_context_connect() failed: Connection refused $ netstat -lx | grep pulse unix 3 [ ACC ] STREAM LISTENING 12344 /run/user/1000/pulse/native Any other thoughts? Does it matter that I have "--daemonize=no" in my service file? By the way, if I do not use a systemd service at all, I've been able to get Pulseaudio to run successfully by manually typing "pulseaudio --start" at the command line. That doesn't really help me though, because I need Pulseaudio to be available on bootup, without manual intervention. > On May 22, 2017, at 12:08 PM, Tanu Kaskinen wrote: > > On Mon, 2017-05-22 at 11:21 -0700, Karl Stahl wrote: >> Thanks for the reply! I'm running Raspbian and have pulseaudio >> version 5.0. >> I tried changing it to type=simple, and that fixed the notify issue, >> but it's still not working. This is what I get: >> >> $ paplay test.wav >> connect localhost port 6020: Connection refused >> xcb_connection_has_error() returned true > > These are unfamiliar errors to me... Is your X11 setup unusual? The > first error could be about libpulse trying to connect to X11 using port > 6020, which would be strange, because normally X11 uses unix sockets. > >> Connection failure: Connection refused >> pa_context_connect() failed: Connection refused > > Is pulseaudio running? If it is, paplay doesn't find the socket. That > might be because systemd sets the XDG_RUNTIME_DIR environment variable > for the services it starts, and that affects the socket location, but > your login environment might not have that variable set. Try setting > XDG_RUNTIME_DIR=/run/user/1000 in your login session setup. > > If that doesn't help, run "PULSE_LOG=99 pactl info". That will show > what socket pactl tries to use. You can compare that to the output of > "netstat -lx | grep pulse", that will show what socket the server uses. > > -- > Tanu > > https://www.patreon.com/tanuk > ___ > 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] Service fails on systemctl start. Status always "activating"
On Mon, 2017-05-22 at 11:21 -0700, Karl Stahl wrote: > Thanks for the reply! I'm running Raspbian and have pulseaudio > version 5.0. > I tried changing it to type=simple, and that fixed the notify issue, > but it's still not working. This is what I get: > > $ paplay test.wav > connect localhost port 6020: Connection refused > xcb_connection_has_error() returned true These are unfamiliar errors to me... Is your X11 setup unusual? The first error could be about libpulse trying to connect to X11 using port 6020, which would be strange, because normally X11 uses unix sockets. > Connection failure: Connection refused > pa_context_connect() failed: Connection refused Is pulseaudio running? If it is, paplay doesn't find the socket. That might be because systemd sets the XDG_RUNTIME_DIR environment variable for the services it starts, and that affects the socket location, but your login environment might not have that variable set. Try setting XDG_RUNTIME_DIR=/run/user/1000 in your login session setup. If that doesn't help, run "PULSE_LOG=99 pactl info". That will show what socket pactl tries to use. You can compare that to the output of "netstat -lx | grep pulse", that will show what socket the server uses. -- 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] Service fails on systemctl start. Status always "activating"
Thanks for the reply! I'm running Raspbian and have pulseaudio version 5.0. I tried changing it to type=simple, and that fixed the notify issue, but it's still not working. This is what I get: $ paplay test.wav connect localhost port 6020: Connection refused xcb_connection_has_error() returned true Connection failure: Connection refused pa_context_connect() failed: Connection refused > On May 22, 2017, at 10:58 AM, Tanu Kaskinen wrote: > > On Mon, 2017-05-22 at 09:03 -0700, Karl Stahl wrote: >> I'm trying to get pulseaudio running on a Raspberry Pi 3 (ARM). I'm >> having trouble getting the service to start properly. The status >> always says "activating", but never seems to finish. Any ideas? > > What's the pulseaudio version? Raspbian ships 5.0, and if you have > that, then pulseaudio doesn't notify systemd when it has started. > Systemd expects that notification, since you set type=notify in the > service file. You can try type=simple instead. > > -- > Tanu > > https://www.patreon.com/tanuk > ___ > 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] Service fails on systemctl start. Status always "activating"
On Mon, 2017-05-22 at 09:03 -0700, Karl Stahl wrote: > I'm trying to get pulseaudio running on a Raspberry Pi 3 (ARM). I'm > having trouble getting the service to start properly. The status > always says "activating", but never seems to finish. Any ideas? What's the pulseaudio version? Raspbian ships 5.0, and if you have that, then pulseaudio doesn't notify systemd when it has started. Systemd expects that notification, since you set type=notify in the service file. You can try type=simple instead. -- Tanu https://www.patreon.com/tanuk ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] Service fails on systemctl start. Status always "activating"
Hi, I'm trying to get pulseaudio running on a Raspberry Pi 3 (ARM). I'm having trouble getting the service to start properly. The status always says "activating", but never seems to finish. Any ideas? $ systemctl --user start pulseaudio.service Job for pulseaudio.service failed. See 'systemctl status pulseaudio.service' and 'journalctl -xn' for details. $ systemctl status pulseaudio.service ● pulseaudio.service Loaded: not-found (Reason: No such file or directory) Active: inactive (dead) $ systemctl --user status pulseaudio.service ● pulseaudio.service - Sound Service Loaded: loaded (/home/pi/.config/systemd/user/pulseaudio.service; enabled) Active: activating (start) since Mon 2017-05-22 08:57:37 PDT; 5s ago Main PID: 3351 (pulseaudio) CGroup: /user.slice/user-1000.slice/user@1000.service/pulseaudio.service └─3351 /usr/bin/pulseaudio --daemonize=no # - ~/.config/systemd/user/pulseaudio.service # - [Unit] Description=Sound Service Requires=pulseaudio.socket [Service] Type=notify ExecStart=/usr/bin/pulseaudio --daemonize=no Restart=on-failure [Install] Also=pulseaudio.socket WantedBy=default.target ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss