[pulseaudio-discuss] Stepping down as a maintainer
Hello all! I have decided to start biotechnology studies, and some things in my life need to give room for that. PulseAudio work is one of those, so starting from 2022-08-22 I wish to drop all responsibilities implied by the maintainer status. How completely I will disappear from the project remains to be seen (I will lurk in the IRC channel at least), but given that lately I have already had very little time for PulseAudio, finding time for further contributions seems quite unlikely. It's been a long journey, and apart from my first summer job, my entire career in software has revolved around PulseAudio. Now is the time for something competely different. Thank you all for being such a pleasant community to work with! -- Tanu
Re: [pulseaudio-discuss] [PATCH] add judgment logic before pa_streq
On Thu, 2022-06-30 at 16:23 +0800, lishengyu wrote: > --- > src/modules/module-switch-on-port-available.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/src/modules/module-switch-on-port-available.c > b/src/modules/module-switch-on-port-available.c > index de9c87092..53c5a0b32 100644 > --- a/src/modules/module-switch-on-port-available.c > +++ b/src/modules/module-switch-on-port-available.c > @@ -393,6 +393,9 @@ static pa_hook_result_t > card_profile_available_hook_callback(pa_core *c, pa_card > if (profile->available != PA_AVAILABLE_NO) > return PA_HOOK_OK; > > +if (!card->active_profile) > +return PA_HOOK_OK; > + > if (!pa_streq(profile->name, card->active_profile->name)) > return PA_HOOK_OK; > Thanks for the patch! Before applying it I would like to know how active_profile could possibly be NULL here, though. If a card has any profiles, one of them has to be active. PS. The best way to submit patch is by making a merge request on GitLab, https://gitlab.freedesktop.org/pulseaudio/pulseaudio -- Tanu
Re: [pulseaudio-discuss] Why does the USB headset show the Digital Output (S/PDIF) port?
On Tue, 2022-06-28 at 15:21 +0800, zhaochen...@uniontech.com wrote:
> Hi guys,
>
> I have a USB headset that the module is Edifier USB K800.
> Plug it into the PC's usb port, and then I found "Digital Output
> (S/PDIF)" audio port as below.
>
> Would you please tell me why the Digital Output (S/PDIF) port has been
> shown, and how to verify if this USB headset really have the output
> function of Digital Output (S/PDIF), and how to close this audio port.
>
> Thanks a lot!
Many USB sound cards show non-existent S/PDIF devices, probably because
the default configuration in ALSA maps both analog and digital to
device 0. It's possible to disable the S/PDIF output in
/usr/share/alsa/cards/USB-Audio.conf, see the section starting with
USB-Audio.pcm.iec958_device {
There you can add your sound card's name, the only problem is that I
haven't figured out what name should be used. Some ideas to try (the
999 part makes the device number for S/PDIF to be 999, which does not
work and therefore PulseAudio will stop showing the S/PDIF output):
"USB PnP Sound Device" 999
"C-Media Electronics Inc. USB PnP Sound Device" 999
"Edifier USB K800" 999
Restart PulseAudio to test your changes.
-- Tanu
[pulseaudio-discuss] [ANNOUNCE] PulseAudio 16.1
Hello everybody, The 16.0 release had some regressions, so here comes a bugfix release to remedy those (along with some other fixes). These are the changes: * Fix parsing of percentage volumes with decimal points in pactl * Fix crash with the "pacmd play-file" command when reads from the disk aren't frame-aligned * Fix module-rtp-recv sometimes thinking it's receiving an Opus stream when it's not * Fix frequent crashing in module-combine-sink, regression in 16.0 * Fix crashing on 32-bit architectures when using the GStreamer codecs for LDAC and AptX Tarball: https://www.freedesktop.org/software/pulseaudio/releases/pulseaudio-16.1.tar.xz SHA256: 8eef32ce91d47979f95fd9a935e738cd7eb7463430dabc72863251751e504ae4 -- Tanu
Re: [pulseaudio-discuss] pactl percentage bug fix
On Sat, 2022-06-04 at 23:05 -0700, Sean Greenslade wrote: > On Sun, Jun 05, 2022 at 01:51:55AM +0100, Patrick May wrote: > > On 04/06/2022 08:48, Sean Greenslade wrote: > > > > > While debugging, I did notice another issue that I was uncertain of how > > > to solve. The detection of absolute values vs. relative values is based > > > on the presence of a plus or minus at the start of the value. This is > > > fine for everything except decibels, since absolute decibel values will > > > often be negative numbers. The way the code sits now, it's impossible to > > > pass an absolute negative decibel value. Probably not a huge deal, but > > > it seemed worth pointing out. > > > > I tested it with > > > > pactl -- set-sink-volume 0 0db > > > > and it sets the volume to 100%. So the ability to specify absolute decibel > > values is only useful if you like blasting stuff at greater than or equal to > > 100% volume > > As I said, it's a bug. When I said it's probably not a huge deal, I > meant in the sense that I doubt many people have ever tried to use the > decibel versions of this command, seeing as this bug makes the absolute > decibel inputs nearly useless. > > My reason for bringing it up was to try and solicit opinions on how best > to fix it. The current method of assuming a "-" always means relative is > not good, but I can't think of a clean way to fix it. Less clean options > that jump to mind: > - Add a new command, e.g. "set-sink-decibels-absolute -3dB" > - Add a new suffix variant, e.g. "set-sink-volume -3dBAbs" > (note that "dBA" is not acceptable, since that has a specific meaning > with regards to sound measurement) > - Have a prefix for absolute numbers, e.g. "set-sink-volume =-3dB" > > What do other people think? There probably aren't any nice-looking solutions to this... My suggestion would be to use pactl set-sink-volume --absolute/--relative sinkname -3dB -- Tanu
[pulseaudio-discuss] [ANNOUNCE] paprefs 1.2
Hey everyone, a new paprefs version became available just now! It's not that different from the old version, though, but you (especially distro packagers) should upgrade soon in order to keep paprefs working with new PulseAudio versions. This is the new stuff in version 1.2: * Compatibility with the upcoming PulseAudio version 16.0. PulseAudio will adjust its module paths, and since paprefs checks what modules are installed by looking for them in the file system, old paprefs versions won't work with the new PulseAudio version. paprefs 1.2 will work with both old and new PulseAudio versions. * A fix for a crash that would happen when trying to install missing PulseAudio modules from paprefs. * Translation updates and new translations for Galician, Kazakh, Korean, Lithuanian, Norwegian Nynorsk and Sinhala. The tarball: http://freedesktop.org/software/pulseaudio/paprefs/paprefs-1.2.tar.xz SHA256: b3f21e40dc3936d15e3ffc910fb0c07c14b88e8c287715b456a948c17638f633 git shortlog Andika Triwidada (1): Added translation using Weblate (Indonesian) Arun Raghavan (1): doc: Drop email as a patch submission method Balázs Meskó (1): Translated using Weblate (Hungarian) Baurzhan Muftakhidinov (1): Translated using Weblate (Kazakh) Daniel Muñiz Fontoira (1): Translated using Weblate (Galician) Emilio Herrera (1): Translated using Weblate (Spanish) Enol P (1): Added translation using Weblate (Asturian) Ettore Atalan (1): Translated using Weblate (German) Geert Warrink (1): Translated using Weblate (Dutch) Gogo Gogsi (1): Translated using Weblate (Croatian) Göran Uddeborg (1): Translated using Weblate (Swedish) Hela Basa (2): Added translation using Weblate (Sinhala) Translated using Weblate (Sinhala) Jean-Baptiste Holcroft (1): Translated using Weblate (French) Julien Humbert (2): Translated using Weblate (French) Translated using Weblate (French) Karl Ove Hufthammer (1): Translated using Weblate (Norwegian Nynorsk) Lv Genggeng (1): Translated using Weblate (Chinese (Simplified) (zh_CN)) Manuela Silva (1): Translated using Weblate (Portuguese) Matsuda Hiroyuki (1): Added translation using Weblate (Japanese) Milo Casagrande (2): Translated using Weblate (Italian) Translated using Weblate (Italian) Moo (1): i18n: added Lithuanian translation Ondrej Sulek (1): Translated using Weblate (Slovak) Oğuz Ersen (2): Translated using Weblate (Turkish) Translated using Weblate (Turkish) Piotr Drąg (1): Translated using Weblate (Polish) Pjotr Vertaalt (1): Translated using Weblate (Dutch) Rafael Fontenelle (1): Translated using Weblate (Portuguese (Brazil)) Ricky Tigg (1): Translated using Weblate (Finnish) Sabri Ünal (1): Translated using Weblate (Turkish) Tanu Kaskinen (8): Fix ustring initialization from a NULL pointer i18n: remove [encoding: UTF-8] from POTFILES.in i18n: Add paprefs.pot to version control README: Add a pointer to Weblate for translators Fix indentation Update module directory logic README: Add a news item for the 1.2 release Prepare for releasing 1.2 Toni Estevez (1): Translated using Weblate (Spanish) Weblate (2): Update translation files Update translation files Yaron Shahrabani (2): Added translation using Weblate (Hebrew) Translated using Weblate (Hebrew) Yi-Jyun Pan (2): Added translation using Weblate (Chinese (Traditional)) Translated using Weblate (Chinese (Traditional)) Yuri Chornoivan (1): Translated using Weblate (Ukrainian) scootergrisen (1): Translated using Weblate (Danish) simmon (1): Translated using Weblate (Korean) -- Tanu
Re: [pulseaudio-discuss] Which device-string I should disable between hw:%f and iec958:%f?
On Wed, 2021-12-22 at 22:01 +0800, 赵成义 wrote:
> Hi guys,
>
>
> I found that some usb earphones can match the device-strings hw:%f
> and iec958:%f of the default.conf configuration file
> at the same time, so two output ports will be displayed, one is the
> analog output and the other is the S/PDIF digital output.
>
>
> Is there any difference between these two outputs? Which device-
> string I should disable between hw:%f and iec958:%f?
> and how can I disable one of them?
iec958:%f is meant for S/PDIF, which is a certain kind of a physical
connector. Earphones are very unlikely to have such connector. If the
connector doesn't exist, that's an issue somewhere below PulseAudio:
alsa configuration (most likely), kernel driver or hardware. If you get
audio when using that output, then the iec958 device is probably just
an alias for the hw device. If the earphones support hardware volume
controls, then there's a difference between iec958 and hw in that
PulseAudio won't use hardware volume control with the iec958 output.
Probably the correct way to disable the iec958 output is to add your
device to this file
https://github.com/alsa-project/alsa-lib/blob/master/src/conf/cards/USB-Audio.conf
(and submit your change to ALSA upstream). More specifically, the file
contains this section which has a list of devices that should have
their iec958 output disabled:
# If a device does not use the first PCM device for digital data, the device
# number for the iec958 device can be changed here.
USB-Audio.pcm.iec958_device {
# "NoiseBlaster 3000" 42
"USB Sound Blaster HD" 1
"Xonar U7" 1
"ASUS XONAR U5" 1
"XONAR U5" 1
"XONAR SOUND CARD" 1
"Xonar SoundCard" 2
# The below don't have digital in/out, so prevent them from being
opened.
"Andrea PureAudio USB-SA Headset" 999
"Blue Snowball" 999
"C-Media USB Headphone Set" 999
"HP Digital Stereo Headset" 999
"GN 9330" 999
...
The file is installed in /usr/share/alsa/cards/USB-Audio.conf.
Your problem description contains one weird thing: The mono-fallback
device has the "fallback = yes" option set, which means that it should
be available only if nothing else works. That means that it should be
impossible to have it available at the same time as iec958-stereo.
Maybe that's a bug in PulseAudio.
-- Tanu
Re: [pulseaudio-discuss] pulseaudio failed to start at ubuntu 21.04
On Sat, 2021-12-18 at 05:51 +0800, su wrote: > pulseaudio failed to start with a usb remote pluged into the embedded pc . > The error message at journalctl is : > > > -- Boot 37de7028dfda47569d03504658160650 -- > Dec 11 04:46:09 hirsute-server systemd[1958]: Starting Sound Service... > Dec 11 04:46:10 hirsute-server pulseaudio[1967]: No such profile: > output:hdmi-stereo > Dec 11 04:46:10 hirsute-server pulseaudio[1967]: Failed to initialize daemon > due to errors while executing startup commands. Source of commands: > /etc/pulse/> > Dec 11 04:46:10 hirsute-server systemd[1958]: pulseaudio.service: Main > process exited, code=exited, status=1/FAILURE > Dec 11 04:46:10 hirsute-server systemd[1958]: pulseaudio.service: Failed with > result 'exit-code'. > Dec 11 04:46:10 hirsute-server systemd[1958]: Failed to start Sound Service. > Dec 11 04:46:10 hirsute-server systemd[1958]: pulseaudio.service: Scheduled > restart job, restart counter is at 1. > Dec 11 04:46:10 hirsute-server systemd[1958]: Stopped Sound Service. > Dec 11 04:46:10 hirsute-server systemd[1958]: Starting Sound Service... > Dec 11 04:46:11 hirsute-server pulseaudio[2087]: No such profile: > output:hdmi-stereo > Dec 11 04:46:11 hirsute-server pulseaudio[2087]: Failed to initialize daemon > due to errors while executing startup commands. Source of commands: > /etc/pulse/> > Dec 11 04:46:11 hirsute-server systemd[1958]: pulseaudio.service: Main > process exited, code=exited, status=1/FAILURE > Dec 11 04:46:11 hirsute-server systemd[1958]: pulseaudio.service: Failed with > result 'exit-code'. > Dec 11 04:46:11 hirsute-server systemd[1958]: Failed to start Sound Service. > Dec 11 04:46:11 hirsute-server systemd[1958]: pulseaudio.service: Scheduled > restart job, restart counter is at 2. > > > This case only applies to a usb remote with microphone and it only happens > during cool boot of the embedded pc. Another word , pulseaudio works if the > pc boots without the remote. > And pulseaudio works too with the usb remote plugged in after system boots. > Please note that this case happens with another usb remote ( with different > usb vendor ID ) too. > If you need more info. , please donot hesitate to let me know. Thanks ! "No such profile" is printed in two cases: * module-alsa-card is loaded with the "profile=" argument, but the specified profile is not found * The startup script contains a set-card-profile command, or you run "pacmd set-card-profile", and the specified profile is not found. What do you have in /etc/pulse/default.pa and /etc/pulse/system.pa? -- Tanu
Re: [pulseaudio-discuss] Start condition failed - ConditionUser=!root not met
On Thu, 2021-11-04 at 11:35 +, Joel wrote: > Tanu - > > Briefly, from the systemctl status reports, errors for the two > machines where system-wide pulseaudio, failed that appear to be the > most significant are as follows: > > ASUS-based desktop (linux-3): line 50. Nov 01 15:53:43 linux-3.home > pulseaudio[7348]: Denied access to client with invalid authentication > data. That's printed when a client tries to connect but is not allowed. Is your user in the pulse-access group? > > Dell laptop (linux-7): line 74. Job for pulseaudio.service failed > because the control process exited with error code. Something went wrong in the startup. If you try running (as root) "pulseaudio --system -vv", does that fail, and if it does, what is the error message (and the preceding log messages)? The command starts pulseaudio in the terminal with verbose logging and logs go to the terminal too. If the startup succeeds, use ctrl-c to stop pulseaudio. -- Tanu
Re: [pulseaudio-discuss] Where are stored sinks' settings?
On Sun, 2021-10-24 at 21:09 -0400, Pierre-Luc Daoust wrote: > Hi everybody! > > I have a question that might look noob. All the settings from Pavucontrol, > about which input sink goes to which output sink, where are they stored? I > know how to list them with pacmd, but if I want to look through the > persistent data in the appropriate config file, which one would it be? My > distro is Manjaro. Sink input routing is stored in ~/.config/pulse/*-stream-volumes.tdb (or .gdb, I don't know if some distributions still use the gdbm format for the PulseAudio databases). There's unfortunately no user-friendly tool for inspecting the database contents, but Debian has the tdb-tools package which probably contains some tool for inspecting tdb files, I haven't tried myself. -- Tanu
Re: [pulseaudio-discuss] Start condition failed - ConditionUser=!root not met
Hi Colin! On Thu, 2021-10-14 at 13:18 +0100, Colin Guthrie wrote: > Tanu Kaskinen wrote on 13/10/2021 20:25: > > On Wed, 2021-10-13 at 14:51 +, Joel wrote: > > > Tanu - > > > > > > Thank you. I made the changes you suggested (removed > > > pulseaudio.socket from two locations where I found the file: > > > /etc/systemd/system/and /etc/systemd/system/sockets.targets.wants. > > > In the file pulseaudio.service, I commented out the lines > > > "Requires=pulseaudio.socket"; "ConditionUser=!root" and > > > "Also=pulseaudio.socket". Please note that there also two > > > occurrences of this file: /etc/systemd/system/and > > > /etc/systemd/system/multi-user.targets.wants. Perhaps the second > > > occurrences are system-generated. > > > > > > I then had sound from the web browser! VLC was still providing sound > > > as before (but I gather not using pulsesaudio). After logging out > > > then logging back in (not rebooting), there was no web browser sound > > > and a new error: Failed to load module "module-x11-publish". This > > > also occurred after rebooting and booting from a cold start. After > > > the reboot, a further error arose: Error opening PCM device front:0: > > > Device or resource busy. Also, the /var/run/.pulse cookie does > > > exist. The systemctl status reports in full are at > > > https://susepaste.org/99540079 . I'm unable to determine what I did > > > to cause these errors. > > > > The module-x11-publish error is probably caused by > > /etc/xdg/autostart/pulseaudio.desktop, which is loaded on login, > > causing /usr/bin/start-pulseaudio-x11 to be run. You could try removing > > the pulseaudio.desktop file (take a backup if you want). You shouldn't > > lose any essential functionality by doing that (and since PulseAudio > > was unable to connect to X11, whatever PulseAudio wanted to do didn't > > succeed anyway). > > > > If you see "Device or resource busy", something else is using the ALSA > > device. You can check with "lsof /dev/snd/*" what programs are using > > the ALSA devices. > > Forgive my ignorance since it's been *years* since I did any PA hacking > (just a drive by message on the list as I clicked on the folder in my > email client!) but do you really want your system-wide PA instance > running as root (that's what the systemd unit files suggests!) > > Wouldn't you want a User=pulse in there in the system unit (and make > sure the user pulse can access the audio devices via suitable ACLs/group > ownerships) PulseAudio does the user switch from root to pulse by itself, I don't know if PulseAudio can handle it if you start it directly as the pulse user. > It would be fine to have a system-wide pulseaudio.socket here that > started up the system-wide pulseaudio.service? Yes, it would be fine, if you configure it right. > Or have things changed so much that the system-wide pulseaudio instance > no longer runs as the pulse user? Nope, I don't think there has been much changes to the system-wide mode at all :) -- Tanu
Re: [pulseaudio-discuss] Start condition failed - ConditionUser=!root not met
On Wed, 2021-10-13 at 14:51 +, Joel wrote: > Tanu - > > Thank you. I made the changes you suggested (removed > pulseaudio.socket from two locations where I found the file: > /etc/systemd/system/and /etc/systemd/system/sockets.targets.wants. > In the file pulseaudio.service, I commented out the lines > "Requires=pulseaudio.socket"; "ConditionUser=!root" and > "Also=pulseaudio.socket". Please note that there also two > occurrences of this file: /etc/systemd/system/and > /etc/systemd/system/multi-user.targets.wants. Perhaps the second > occurrences are system-generated. > > I then had sound from the web browser! VLC was still providing sound > as before (but I gather not using pulsesaudio). After logging out > then logging back in (not rebooting), there was no web browser sound > and a new error: Failed to load module "module-x11-publish". This > also occurred after rebooting and booting from a cold start. After > the reboot, a further error arose: Error opening PCM device front:0: > Device or resource busy. Also, the /var/run/.pulse cookie does > exist. The systemctl status reports in full are at > https://susepaste.org/99540079 . I'm unable to determine what I did > to cause these errors. The module-x11-publish error is probably caused by /etc/xdg/autostart/pulseaudio.desktop, which is loaded on login, causing /usr/bin/start-pulseaudio-x11 to be run. You could try removing the pulseaudio.desktop file (take a backup if you want). You shouldn't lose any essential functionality by doing that (and since PulseAudio was unable to connect to X11, whatever PulseAudio wanted to do didn't succeed anyway). If you see "Device or resource busy", something else is using the ALSA device. You can check with "lsof /dev/snd/*" what programs are using the ALSA devices. -- Tanu
Re: [pulseaudio-discuss] Start condition failed - ConditionUser=!root not met
On Mon, 2021-10-11 at 22:19 +, Joel wrote: > Tanu - > > Thank you for your response. Please note - I have very little experience > with pulseaudio and alsa, except as a user. When it comes to the > configuration, I'm a complete novice and concluded that I made a mistake > somewhere by copying these files. > > Yes, I copied the file from user library and it does contain the following > lines (16 & 17): > >Requires=pulseaudio.socket >ConditionUser=!root > > Here is a link to the complete pulseaudio.service file: > https://susepaste.org/20298491 > > I gather that the comments preceding those lines hint at the problem I > created. > > For completeness, here is a link to the modified client.conf file: > https://susepaste.org/83477827 > > What do you suggest I do here? You don't need pulseaudio.socket if you're starting pulseaudio at boot, so remove that file and from pulseaudio.service remove the "Requires=pulseaudio.socket" and "Also=pulseaudio.socket" lines. Also remove the "ConditionUser=!root" line. -- Tanu
Re: [pulseaudio-discuss] Start condition failed - ConditionUser=!root not met
On Mon, 2021-10-11 at 15:41 -0400, Joel Miller wrote: > OS: openSuSE Leap 15.3; KDE plasma desktop > > To enable a system instance of pulseaudio, I made the following file > modifications suggested on the freedesktop.org > (https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/SystemWide/) > > and rudd-o websites > (https://rudd-o.com/linux-and-free-software/how-to-make-pulseaudio-run-once-at-boot-for-all-your-users): > > Per freedesktop.org: > set autospawn = no in /etc/pulse/client.conf > added "root" and "jm" to pulse-access > > Per rudd-o: > in /etc/systemd/system/pulseaudio.service, modified text for [service] > and [Install] (see rudd-o) > used systemctl to enable, start, and check the status of pulseaudio > > The status request yields the following: > > linux-6:/etc/systemd/system # systemctl --system status pulseaudio.service > ● pulseaudio.service - Sound Service > Loaded: loaded (/etc/systemd/system/pulseaudio.service; enabled; > vendor preset: disabled) > Active: inactive (dead) > TriggeredBy: ● pulseaudio.socket >Condition: start condition failed at Wed 2021-10-06 12:16:38 EDT; 4s ago > └─ ConditionUser=!root was not met > > * * * > > Your suggestions and advice are welcome. > > Joel > 973 736 8306 Does /etc/systemd/system/pulseaudio.service contain "ConditionUser=!root"? The systemctl status output looks like it does, but that doesn't make sense in a system service (and the rudd-o page doesn't contain that line, so I don't know why you would have that, unless you copied the user service to the system service, but in your list of modifications you didn't say that you did so). The systemctl output also indicates that pulseaudio.service was triggered by pulseaudio.socket, so check also that (the system version of) pulseaudio.socket doesn't contain "ConditionUser=!root". Again, rudd-o doesn't instruct you to set up a socket activation unit, nor did you mention doin that in your message, so I don't understand why pulseaudio.socket would be involved at all. -- Tanu
Re: [pulseaudio-discuss] Force SRC even when sample rates are the same
On Mon, 2021-10-11 at 19:03 +0300, Timur Aydin wrote: > Hello folks, > > Is there a way to force pulse audio to use SRC even when the input and > output sample rates are the same? No. -- Tanu
Re: [pulseaudio-discuss] Why does Jack section uses "state.plugged = unknown" and "state.unplugged = unknown"?
On Fri, 2021-09-17 at 11:41 +0800, Chengyi Zhao wrote: > Hi guys, > > I don't know why Jack section uses "state.plugged = unknown" and > "state.unplugged = unknown" in the path file > "analog-output-lineout.conf" below. > > I think PulseAudio should set Jack to be available when it recognizes > the "Jack Line Out CLFE" is plugged, and vice versa. > > Would you please help explain the true meaning of ”unknown“ here. > > [Jack Line Out CLFE] > state.plugged = unknown > state.unplugged = unknown > required-any = any The center/LFE channel alone isn't a good source for lineout availability information, so we ignore it for that purpose. If you have only center/LFE connected but not the front channels, neither stereo nor surround output is really functional. If you don't have center/LFE connected, the path may or may not be functional, depending on whether you're using stereo or surround. If we had separate lineout path configurations for stereo and the various surround profiles, then we could perhaps use "state.unplugged = no" to mark the surround output unavailable when center/LFE isn't connected. -- Tanu
Re: [pulseaudio-discuss] pulsectl with pulseaudio 15.0
On Wed, 2021-09-08 at 07:35 +, Matthias Mirbeth wrote: > Hello all, > > I am using the pulsectl module to interact with the pulseaudio C API from my > python application. > This worked fine with pulseaudio 14.2 and previous versions but I can't get > it to work with pulseaudio 15. > > Upon debugging the python code I found out that the state callback (assigned > with pa_context_set_state_callback() ) gets called with a CONNECTIONREFUSED > error right after the pa_context_connect() function is called. > > > I built and installed pulseaudio from the git repository like this: > > meson -Dbluez5-native-headset=false -Dbluez5-ofono-headset=true > -Dbluez5=enabled -Dx11=disabled -Dalsa=enabled -Dtests=false ./build > > ninja -C build > > sudo ninja -C build install > > In the release notes I did not see anything related to the C API. Did I miss > something there? > Do I need to configure something differently? "Connection refused" usually means that pulseaudio is not running or libpulse is looking for the socket at a wrong place for some reason. If pulseaudio is running, you can find the socket that pulseaudio is listening at with "sudo netstat -xp | grep pulse". You can find what socket the application is trying to connect to with "PULSE_LOG=4 myapp". -- Tanu
[pulseaudio-discuss] [ANNOUNCE] pavucontrol 5.0
Hello, all! Version 5.0 of pavucontrol is out now! This release contains these changes: * Support for switching Bluetooth codecs (new in PulseAudio 15.0). * Support for locking card profiles (new in PulseAudio 15.0). Locking a profile prevents PulseAudio from automatically switching away from that profile on plug/unplug events. * New translations: Asturian, Basque, Belarusian, Galician, Hebrew, Kazakh, Norwegian Bokmål, Sinhala, Slovenian * Updated translations: Catalan, Chinese (Simplified), Chinese (Traditional), Croatian, Danish, Dutch, Finnish, French, German, Hungarian, Italian, Japanese, Korean, Lithuanian, Norwegian Nynorsk, Polish, Portugese, Portugese (Brazil), Slovak, Spanish, Swedish, Turkish, Ukrainian. * Some bug fixes. * New dependency: json-glib. * Minimum gtkmm version bumped to 3.22. Thank you all who contributed! The tarball: https://freedesktop.org/software/pulseaudio/pavucontrol/pavucontrol-5.0.tar.xz SHA256: ce2b72c3b5f1a70ad0df19dd81750f9455bd20870d1d3a36d20536af2e8f4e7a git shortlog Allan Nordhøy (2): i18n: Correct spelling "AC-3" and "E-AC-3" Translated using Weblate (Norwegian Bokmål) Ammuu5 (1): i18n: Update Finnish translation Anonymous (2): Update translation files Translated using Weblate (Portuguese) Arun Raghavan (1): doc: Drop email as a method of patch submission Balázs Meskó (1): Translated using Weblate (Hungarian) Baurzhan Muftakhidinov (1): Translated using Weblate (Kazakh) Bendegúz Gyönki (1): Translated using Weblate (Hungarian) Butterfly (1): i18n: Update Turkish translations file Christoph Haag (1): mainwindow: escape nameLabel Daniel Muñiz Fontoira (3): Translated using Weblate (Galician) Translated using Weblate (Galician) Translated using Weblate (Galician) Dusan Kazik (1): Translated using Weblate (Slovak) Emilio Herrera (1): Translated using Weblate (Spanish) Enol P (1): Added translation using Weblate (Asturian) Fabian Affolter (1): Translated using Weblate (German) Felipe Sateler (1): Migrate away from deprecated Gtk interfaces Geert Warrink (2): Translated using Weblate (Dutch) Translated using Weblate (Dutch) Göran Uddeborg (3): Translated using Weblate (Swedish) Translated using Weblate (Swedish) Translated using Weblate (Swedish) Hela Basa (1): Added translation using Weblate (Sinhala) Henrique Roberto Gattermann Mittelstaedt (1): Translated using Weblate (Portuguese (Brazil)) Igor V. Kovalenko (6): mainwindow: do not erase from container while iterating card: implement bluetooth profile codec selection card: do not quit on error sending message to object card: use JSON with pulseaudio messaging API cardwidget: add flag to lock profile from switching automatically Disconnect and unreference all peak indicator stream objects Jamison Lofthouse (1): Set channel label width to 12 Jan Kuparinen (3): Translated using Weblate (Finnish) Translated using Weblate (Finnish) Translated using Weblate (Finnish) Jiri Grönroos (1): Translated using Weblate (Finnish) Julien Humbert (3): Translated using Weblate (French) Translated using Weblate (French) Translated using Weblate (French) Karl Ove Hufthammer (4): Translated using Weblate (Norwegian Nynorsk) Translated using Weblate (Norwegian Nynorsk) Translated using Weblate (Norwegian Nynorsk) Translated using Weblate (Norwegian Nynorsk) Leon Kowarschick (1): add gtk window class to mainwindow. Manuela Silva (2): Translated using Weblate (Portuguese) Translated using Weblate (Portuguese) Milo Casagrande (1): Translated using Weblate (Italian) Milo Ivir (1): Translated using Weblate (Croatian) Moo (1): i18n: Update lt.po Nejc Bertoncelj (1): Translated using Weblate (Slovenian) Nishide Itaru (1): Translated using Weblate (Japanese) Ondrej Sulek (3): Translated using Weblate (Slovak) Translated using Weblate (Slovak) Translated using Weblate (Slovak) Oğuz Ersen (3): Translated using Weblate (Turkish) Translated using Weblate (Turkish) Translated using Weblate (Turkish) Piotr Drąg (3): i18n: Update Polish translation Translated using Weblate (Polish) Translated using Weblate (Polish) Pjotr Vertaalt (1): Translated using Weblate (Dutch) Porrumentzio (2): Translated using Weblate (Basque) Translated using Weblate (Basque) Rafael Fontenelle (1): Translated using Weblate (Portuguese (Brazil)) Tanu Kaskinen (17): mainwindow: scale icons to sane size mainwindow: set the updating flag later for sinks and sources devicewidget: fix the enabling logic of the advanced options expander streamwidget: Use a drop-down list instead of
Re: [pulseaudio-discuss] Why should we set multichannel-input and multichannel-output to a fallback map
On Fri, 2021-04-02 at 17:49 +0800, Chengyi Zhao wrote: > Hi guys, > > I don't know why we should set multichannel-input and > multichannel-output to fallback map > in the configuration file default.conf. > > I think these have no actual usage scenarios, we should delete these > configurations. > > Do you agree with me？ > > > ./src/modules/alsa/mixer/profile-sets/default.conf： > > -[Mapping multichannel-output] > -device-strings = hw:%f > -channel-map = left,right,rear-left,rear-right > -exact-channels = false > -fallback = yes > -priority = 1 > -direction = output > - > -[Mapping multichannel-input] > -device-strings = hw:%f > -channel-map = left,right,rear-left,rear-right > -exact-channels = false > -fallback = yes > -priority = 1 > -direction = input > - These are used with sound cards that can't be opened with the regular mappings. Some pro audio cards can have e.g. 12 channels and refuse to be opened with any less channels. The "exact-channels" option is set to false with the multichannel mappings, which means that no matter how many channels the card requires, these mappings successfully open the device. -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [ANNOUNCE] PulseAudio 14.2
Hi all, The 14.1 release contained a patch that broke unplug event handling[1], affecting a vast number of users, so here comes 14.2 with that bug fixed. There are no other changes. Tarball: https://www.freedesktop.org/software/pulseaudio/releases/pulseaudio-14.1.tar.xz SHA256: 75d3f7742c1ae449049a4c88900e454b8b350ecaa8c544f3488a2562a9ff66f1 [1] https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/1096 -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] May I modify the configuration of the path 'analog-output-lineout.conf'
On Tue, 2020-11-24 at 05:42 +, Chengyi Zhao wrote: > Hi guys, > > I found a Jack that it is Line Out CLFE in the sound card 'Realteck ACL662 > rev3', > and this Jack can adapt 'Mapping multichannel-output' of the profile-sets > 'default.conf'. > > Would you please tell me what Line Out CLFE is, and the difference is with > Line Out? thanks. "Line Out CLFE" refers to the center/LFE stereo connector on a sound card that supports surround sound. "Line Out" refers to lineout in general without specifying the channels. I expect that hardware that provides "Line Out CLFE" doesn't have a generic "Line Out" jack control and vice versa. > Because there is a volume issue when to switch port from headphones to Line > Out CLFE, > I will modify the path file 'analog-output-lineout.conf' so that I can fix > this volume issue, > and Line Out CLFE will adapt this path file. > > Would you please tell me if I can make such a modification as below? thanks. > > Previous configuration of analog-output-lineout.conf: > -- > [Jack Line Out CLFE] > state.plugged = unknown > state.unplugged = unknown > required-any = any > > Current configuration of analog-output-lineout.conf: > - > [Jack Line Out CLFE] > required-any = any This change has the effect that if the center/LFE connector is unplugged, the lineout port becomes unavailable. This is not good, if you want to use the sound card in stereo mode and have only the front channels plugged in. -- 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] How to control the right and left channel for a specific application using CLI ?
On Wed, 2020-11-04 at 14:56 +0100, 01iv...@labomedia.org wrote: > Le 2020-11-04 01:17, Arun Raghavan a écrit : > > On Tue, 3 Nov 2020, at 7:09 PM, 01iv...@labomedia.org wrote: > > > Le 2020-11-03 23:49, Arun Raghavan a écrit : > > > > On Tue, 3 Nov 2020, at 5:28 PM, 01iv...@labomedia.org wrote: > > > > > Hello again, > > > > > > > > > > I want to know if there is a way, still in command line, to control > > > > > the > > > > > right and left volumes of an application. > > > > > With Pulseaudio Volume Control, you can click on the lock icon related > > > > > to a launched application, and two sliders appear to do so. > > > > > Is it possible in CLI ? > > > > > > > > > > My goal is to run two applications on the same card, but to assign > > > > > right > > > > > channel for one and left for the other. > > > > > > > > > > Possible complication : the output of my application is in mono and > > > > > with > > > > > Pulseaudio Volume Control I don't get the two sliders if I click on > > > > > the > > > > > lock icon. > > > > > > > > You can use pactl to do this: > > > > > > > > pactl set-sink-input > > > > ... > > > > > > > > You can look up the sink input index and channel map for channel order > > > > with: > > > > > > > > pactl list sink-inputs > > > > > > > > -- Arun > > > > > > Hello Arun and thanks for the quick answer. > > > > > > It's exactly the command I was looking for. > > > Unfortunately, as I thought, it doesn't work in my case because my > > > output is in mono. > > > Here's what I get: > > > Failed to set volume: You tried to set volumes for 2 channels, whereas > > > channel(s) supported = 1 > > > > > > I can't change the output of the software. > > > Is there possibly a way to create a virtual stereo output from the > > > mono > > > > Yup, check out module-remap-sink: > > https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Modules/#module-remap-sink > > > > -- Arun > > Thank you, > > Your answer is good... I just asked the wrong question... Sorry... > > What could help me, in my case, is to remap the mono sink-input (the > ouput of my application) into a stereo one, so that I could control the > volume of each channel with set-sink-input. > Maybe I missed something but module-remap-sink doesn't like to do it. > > I tried to use module-remap-source but "Name or index of the master > source" seems to concern sink listed with "pacmd list-sinks" not "pactl > list sink-inputs". > > Is there a solution to get a stereo sink-input from a mono one ? There's no way to change the channel map of a sink input. It sounds like you could load one remap-sink for the left channel and one remap- sink for the right channel, and point the application to the appropriate remap-sink. -- 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] How to choose the sound card for an application using CLI ?
On Tue, 2020-11-03 at 02:25 +0100, 01iv...@labomedia.org wrote: > Hello, > > I want to run applications with specifics sound cards in command line on > Ubuntu 20.04. > I know it is graphically possible with Pulseaudio Volume Control which > let me choose the card in a menu after the application is launched. > But I want to use command lines so that I can automatize the process in > a bash file (I've got ten sound cards and more to come). > > I've tried "pactl set-default-sink" but it changes the card for all the > applications. > I've looked in "man pulse-cli-syntax" but I didn't find what I'm looking > for. > > I've also tried to use environment variables such as ALSA_CARD= and > ALSA_PCM_CARD= without success. > > Is there a way to do what I want ? Maybe the PULSE_SINK environment variable will do the trick. The variable value is a sink name (to get a list of names, run "pactl list sinks | grep Name"). -- 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] Networking and volume control
On Fri, 2020-10-30 at 17:28 -0500, Matt Garman wrote: > I have PulseAudio set up on a Raspberry Pi as a sound server. The RPi > is connected to a USB DAC, which has hardware volume control > capabilities. This is what I have in my /etc/pulse/default.pa: > > load-module module-alsa-sink control='D70 ' > > Note: I am deliberately NOT loading module-udev-detect, otherwise > PulseAudio reverts to software volume control. (The device is a > Topping D70, and the space between the zero and the quote above is > deliberate.) > > Now, on my Linux workstation, from a terminal, I set > PULSE_SERVER=hostname_of_my_rpi. Then I launch two applications: vlc > and pavucontrol. > > The volumes shown in vlc and pavucontrol start out the same. And if I > raise the volume in vlc, the slider in pavucontrol makes a > corresponding change (as expected). > > However, if I *lower* the volume in vlc, the volume in pavucontrol > stays the same. Which volume? The stream volume (Playback tab) or the device volume (Output Devices tab)? I would expect the stream volume to be always in sync, but if you have flat volumes enabled (which you probably do, judging from your description), then increasing the vlc volume will increase the device volume if necesssary, but lowering the vlc volume will not affect the device volume in pavucontrol. > This is a huge problem: say I temporarily raise the > volume in vlc, and mistakenly set it too loud. I lower it to where it > should be. Now I quit vlc. The actual volume now "jumps" back up to > where it's stuck in pavucontrol! So if I'm not aware of this, the > next app that uses PulseAudio will be way too loud. > > Now, I re-open vlc. I use pavucontrol to lower the volume to zero. > If I raise the volume with pavucontrol, it also goes up in vlc, but by > a different amount. I just raised the volume to 54% in pavucontrol, > but it's showing 22% in vlc. (Whereas, as I noted above, when I > raised it with vlc, the percentages were in lock-step with both > programs.) Furthermore, if I raise the volume in vlc, nothing happens > (i.e. no perceptible change in volume) until I hit 54% in vlc! > > Any thoughts on what's going on here? > > Thanks! You can disable flat volumes in /etc/pulse/daemon.conf by setting "flat-volumes = no" (remember to remove the leading semicolon from the line, it's a comment character). When you do that, the vlc volume will not affect the device volume at all. PulseAudio 13.0 will disable flat volumes by default. You're not the first user who gets confused by the feature, and most distributions already patch daemon.conf to disable flat volumes. -- 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] Why I can't find multichannel-input and multichannel-output paths in path folder
On Wed, 2020-10-28 at 09:59 +0800, Chengyi Zhao wrote: > Hi guys, > > I have a computer with using Realtek ALC662 rev3, it can adapt the > multichannel profile below, > > but I can't find multichannel-input and multichannel-output paths in > path folder > > (/usr/share/pulseaudio/alsa-mixer/paths), please tell me the working > logic of > > multi-channel profile, and how it differs from other profiles, thanks! > > > > [Mapping multichannel-output] > device-strings = hw:%f > channel-map = left,right,rear-left,rear-right > exact-channels = false > fallback = yes > priority = 1 > direction = output > paths-output = multichannel-output > > [Mapping multichannel-input] > device-strings = hw:%f > channel-map = left,right,rear-left,rear-right > exact-channels = false > fallback = yes > priority = 1 > direction = input > paths-input = multichannel-input > > The profile-set configuration indeed references non-existent paths. The "paths-output" and "paths-input" options should be removed from these mappings. The multichannel mappings are tried when nothing else works (hence "fallback = yes"), and the purpose of these mappings is to have some kind of support for sound cards that can only be opened with 4 channels or more, and don't define the standard "surround" alsa device names. The "exact-channels = false" option means that if the sound card requires using more than 4 channels, PulseAudio will open the device with as many channels as necessary, but will only use the first 4 channels as defined with the "channel-map" option. The rest of the channels get assigned "aux" positions, which are not routed to unless an application uses the aux channels its own channel map (which virtually no application does). -- 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] Sound card is detected and used accidentally in PulseAudio
On Mon, 2020-10-26 at 10:34 +0100, Karsten wrote: > Hello developers of PulseAudio, > > it seems that there is nearly nobody that can help with problems with > PulseAudio. > So my hope is that you can help? > > Please be so kind and have a look at this problem. > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972689 > > ALSA is working every time so the problem is that only pulseaudio is ignoring > the sound blaster card. > https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=972689;filename=deactivated.jpg;msg=10 > > This problem exists after Debian 8, so probably with PulseAudio 12.0. > It's independent from the used Frontend, it is the same in KDE and XFCE. > > How can this problem be analyzed? > What must be done with /etc/pulse/client.conf ? > > Best regards > karsten I suggest you run this script (the script was added in PulseAudio 13.0, but probably works with 12.0 too): https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/raw/master/src/utils/pa-info Then create a bug report at https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/new and attach the pa-info output (the output will be too large for the mailing list, and it's anyway better to deal with bugs in the issue tracker). -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Pulseaudio is deadlocked when using module-echo-cancel to Bluetooth input audio
On Fri, 2020-09-25 at 14:00 +0800, Chengyi Zhao wrote: > Hi guys, > > Pulseaudio is deadlocked when Bluetooth(HSP) is selected as the input > audio and module-echo-cancel is loaded. > > I don't know why Thread 1 and Thread 5 are all blocked in the function > futex_abstimed_wait_cancelable. > > Please help analyze the following call stack information, thanks! > > (gdb) info thread >Id Target Id Frame > * 1Thread 0x7f7f23817e00 (LWP 4366) "pulseaudio" > futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, > futex_word=0x7f7f0c0013e0) at > ../sysdeps/unix/sysv/linux/futex-internal.h:205 >2Thread 0x7f7f18818700 (LWP 4601) "alsa-sink-ALC89" > 0x7f7f23feb926 in __GI_ppoll (fds=0x5cc130, nfds=4, > timeout=, sigmask=sigmask@entry=0x0) at > ../sysdeps/unix/sysv/linux/ppoll.c:39 >3Thread 0x7f7f13fa8700 (LWP 4604) "alsa-source-ALC" > 0x7f7f23feb926 in __GI_ppoll (fds=0x7940c0, nfds=4, > timeout=, sigmask=sigmask@entry=0x0) at > ../sysdeps/unix/sysv/linux/ppoll.c:39 >5Thread 0x7f7f13227700 (LWP 6227) "bluetooth" > futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, > futex_word=0x667650) at ../sysdeps/unix/sysv/linux/futex-internal.h:205 > (gdb) bt > #0 0x7f7f24260896 in futex_abstimed_wait_cancelable (private=0, > abstime=0x0, expected=0, futex_word=0x7f7f0c0013e0) at > ../sysdeps/unix/sysv/linux/futex-internal.h:205 > #1 0x7f7f24260896 in do_futex_wait (sem=sem@entry=0x7f7f0c0013e0, > abstime=0x0) at sem_waitcommon.c:111 > #2 0x7f7f24260988 in __new_sem_wait_slow > (sem=sem@entry=0x7f7f0c0013e0, abstime=0x0) at sem_waitcommon.c:181 > #3 0x7f7f242609f9 in __new_sem_wait (sem=sem@entry=0x7f7f0c0013e0) > at sem_wait.c:42 > #4 0x7f7f243846d2 in pa_semaphore_wait (s=0x7f7f0c0013e0) at > pulsecore/semaphore-posix.c:61 > #5 0x7f7f243cc224 in pa_asyncmsgq_send (a=0x717130, > object=, code=code@entry=13, > userdata=userdata@entry=0x697810, offset=offset@entry=0, > chunk=chunk@entry=0x0) at pulsecore/asyncmsgq.c:168 > #6 0x7f7f1f1f5dfe in command_get_playback_latency (pd= out>, command=, tag=9, t=, > userdata=) at pulsecore/protocol-native.c:2873 > #7 0x7f7f2436df7f in pa_pdispatch_run (pd=0x5c9650, > packet=packet@entry=0x6f84c0, ancil_data=ancil_data@entry=0x6e0158, > userdata=userdata@entry=0x6f4600) at pulsecore/pdispatch.c:346 > #8 0x7f7f1f1f95e5 in pstream_packet_callback (p=0x6dfec0, > packet=0x6f84c0, ancil_data=0x6e0158, userdata=0x6f4600) at > pulsecore/protocol-native.c:4951 > #9 0x7f7f2437098d in do_read (p=p@entry=0x6dfec0, > re=re@entry=0x6e0088) at pulsecore/pstream.c:1020 > #10 0x7f7f24373758 in do_pstream_read_write (p=0x6dfec0) at > pulsecore/pstream.c:253 > #11 0x7f7f24373af9 in srb_callback (srb=0x756d90, userdata=0x6dfec0) > at pulsecore/pstream.c:295 > #12 0x7f7f2437434a in srbchannel_rwloop (sr=0x756d90) at > pulsecore/srbchannel.c:190 > #13 0x7f7f242fed28 in dispatch_pollfds (m=0x5cc840) at > pulse/mainloop.c:140 > #14 0x7f7f242fed28 in pa_mainloop_dispatch (m=m@entry=0x5cc840) at > pulse/mainloop.c:898 > #15 0x7f7f242feffc in pa_mainloop_iterate (m=0x5cc840, > block=, retval=0x7ffceef8cde8) at pulse/mainloop.c:929 > #16 0x7f7f242ff0a0 in pa_mainloop_run (m=m@entry=0x5cc840, > retval=retval@entry=0x7ffceef8cde8) at pulse/mainloop.c:945 > #17 0x00407306 in main (argc=, argv= out>) at daemon/main.c:1144 > (gdb) c > Continuing. > ^C > Thread 1 "pulseaudio" received signal SIGINT, Interrupt. > futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, > futex_word=0x7f7f0c0013e0) at > ../sysdeps/unix/sysv/linux/futex-internal.h:205 > 205in ../sysdeps/unix/sysv/linux/futex-internal.h > (gdb) info thread >Id Target Id Frame > * 1Thread 0x7f7f23817e00 (LWP 4366) "pulseaudio" > futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, > futex_word=0x7f7f0c0013e0) at > ../sysdeps/unix/sysv/linux/futex-internal.h:205 >2Thread 0x7f7f18818700 (LWP 4601) "alsa-sink-ALC89" > 0x7f7f23feb926 in __GI_ppoll (fds=0x5cc130, nfds=4, > timeout=, sigmask=sigmask@entry=0x0) at > ../sysdeps/unix/sysv/linux/ppoll.c:39 >3Thread 0x7f7f13fa8700 (LWP 4604) "alsa-source-ALC" > 0x7f7f23feb926 in __GI_ppoll (fds=0x7940c0, nfds=4, > timeout=, sigmask=sigmask@entry=0x0) at > ../sysdeps/unix/sysv/linux/ppoll.c:39 >5Thread 0x7f7f13227700 (LWP 6227) "bluetooth" > futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, > futex_word=0x667650) at ../sysdeps/unix/sysv/linux/futex-internal.h:205 > (gdb) thread 5 > [Switching to thread 5 (Thread 0x7f7f13227700 (LWP 6227))] > #0 futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, > futex_word=0x667650) at ../sysdeps/unix/sysv/linux/futex-internal.h:205 > 205in ../sysdeps/unix/sysv/linux/futex-internal.h >
Re: [pulseaudio-discuss] Questions about device_start_waiting_for_profiles
On Sun, 2020-09-13 at 17:28 +0800, Chengyi Zhao wrote:
> Hi guys,
>
> I have a question for the code below, please give your opinion, thanks!
>
> The function device_start_waiting_for_profiles is to wait for connecting
> profiles,
> but only waited 3 seconds(WAIT_FOR_PROFILES_TIMEOUT_USEC), if Bluetooth
> transport state
> will be changed after 3 seconds(WAIT_FOR_PROFILES_TIMEOUT_USEC),
> I think whether there are any issues with the code logic or not.
>
>
> /* src/modules/bluetooth/bluez5-util.c */
>
> n_disconnected_profiles =
> device_count_disconnected_profiles(t->device);
>
> new_device_appeared = !old_any_connected &&
> pa_bluetooth_device_any_transport_connected(t->device);
> device_disconnected = old_any_connected &&
> !pa_bluetooth_device_any_transport_connected(t->device);
>
> if (new_device_appeared) {
> if (n_disconnected_profiles > 0)
> device_start_waiting_for_profiles(t->device); < here
> else
> pa_hook_fire(>device->discovery->hooks[PA_BLUETOOTH_HOOK_DEVICE_CONNECTION_CHANGED],
>
> t->device);
> return;
> }
>
> static void device_start_waiting_for_profiles(pa_bluetooth_device
> *device) {
> pa_assert(!device->wait_for_profiles_timer);
> device->wait_for_profiles_timer =
> pa_core_rttime_new(device->discovery->core,
> pa_rtclock_now() + WAIT_FOR_PROFILES_TIMEOUT_USEC, < here
> wait_for_profiles_cb, device);
> }
>
> static void wait_for_profiles_cb(pa_mainloop_api *api,
> pa_time_event* event, const struct timeval *tv, void *userdata) {
> pa_bluetooth_device *device = userdata;
> pa_strbuf *buf;
> pa_bluetooth_profile_t profile;
> bool first = true;
> char *profiles_str;
>
> device_stop_waiting_for_profiles(device); < here
>
> /* .. */
> }
>
> Best Regards,
> Chengyi
I don't know what issues you're worried about. I'm not aware of any
issues, to my knowledge the code does what it's designed to do: delay
card creation until all profiles have been connected, but if that takes
more than 3 seconds, then the card is created with some profiles
disabled. We don't want to wait forever if those profiles never
connect.
--
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] The volume control ways in PulseAudio
On Fri, 2020-07-17 at 17:15 +0800, Aaron Chou wrote: > Thanks for your email! > > On Fri, Jul 17, 2020 at 4:20 PM Tanu Kaskinen wrote: > > > On Fri, 2020-07-17 at 10:57 +0800, Aaron Chou wrote: > > > Hi, all: > > > > > > I am the newer about PulseAudio. > > > When I have some time to learn it, I found that there are two ways in > > > volume control, which is software control and hardware control. > > > I can not understand these two ways. > > > The software way means the volume data will not be sent to the hardware? > > > It is unbelievable. > > > > Software volume means that PulseAudio modifies the signal to be softer > > or louder. Hardware volume means that PulseAudio sends the signal > > unmodified and tells the hardware to the modification, which requires > > that the hardware provides an interface for controlling the volume (I'm > > currently using a USB sound card that doesn't provide such interface). > > > em... > I also have an appearance with a USB sound card, and something else is > abnormal. > Such as the volume is set to 0, but it also can play music when the system > reboot or power off. > So I doubt that the volume is not be set to hardware through PulseAudio. > > Can I have the following flow chart： > > app->pulseaudio(software control)->alsa lib->alsa driver If you mean that can you forcibly disable hardware volume, the answer is no, there's currently no such option. > BTW: > Do you know how the USB sound driver receives the volume data from > PulseAudio? > The ioctl? or other else? I can not determine. PulseAudio calls snd_mixer_selem_set_playback_volume() in alsa-lib. I don't know what that function does internally, you can look at its implementation yourself. -- 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] The volume control ways in PulseAudio
On Fri, 2020-07-17 at 10:57 +0800, Aaron Chou wrote: > Hi, all: > > I am the newer about PulseAudio. > When I have some time to learn it, I found that there are two ways in > volume control, which is software control and hardware control. > I can not understand these two ways. > The software way means the volume data will not be sent to the hardware? > It is unbelievable. Software volume means that PulseAudio modifies the signal to be softer or louder. Hardware volume means that PulseAudio sends the signal unmodified and tells the hardware to the modification, which requires that the hardware provides an interface for controlling the volume (I'm currently using a USB sound card that doesn't provide such interface). -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] pulseaudio 13.0 stopped working after system upgrade
On Sun, 2020-07-12 at 20:35 +0200, mailinglis...@posteo.de wrote: > Hi there! > > I just did a distribution upgrade, now pulseaudio 13.0 stopped working. > > > I use a Unix socket setup to allow multiple local users to access the > pulse server. > > In /etc/pulse/default.pa I use these options: > > load-module module-native-protocol-unix socket=/dev/shm/pulse-socket > auth-anonymous=1 > > > The main local user (me...) has no $HOME/.config/pulse/client.conf > > > Now, when doing pulseaudio -D --start - I get this: > > D: [pulseaudio] conf-parser.c: Parsing configuration file > '/etc/pulse/client.conf' > D: [pulseaudio] conf-parser.c: Parsing configuration file > '/etc/pulse/client.conf.d/50-system.conf' > I: [pulseaudio] main.c: Daemon startup successful. > > > But, I have no sound. pactl info gives this error: > > Connection failure: Connection refused That usually means that pactl is trying to connect to a socket that doesn't exist. > The daemon is running. accepting no connections. > > The local user is in groups audio and pulse. Unrelated hint: being in the pulse group isn't useful. When using the group authentication mechanism (which you aren't), you should add users to the pulsea-access group. The pulse user and group is only used as the user/group that pulseaudio runs under in the system mode. Being in the audio group is not really recommended either, because it breaks user switching (when two users are using their own pulseaudio instances, which you aren't doing). > It would be nice if someone has a hint for me! You can use "PULSE_LOG=9 pactl info" to get information about where pactl is trying to connect to. You didn't explain how you have configured clients so that they know to connect to /dev/shm/pulse-socket. -- 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] alsa-ucm: disallow null mdev argument into pa_alsa_open_mixer_by_name()
On Wed, 2020-07-01 at 11:20 +0300, Eero Nurkkala wrote:
> It's possible for mdev to be NULL. In this case, an assert is taken
> in pa_alsa_open_mixer_by_name() with debug builds, and a crash with
> release builds. However, it's possible to bypass this trouble by taking
> the error path if mdev is NULL.
>
> Reported-by: Jarkko Sankala
> Signed-off-by: Eero Nurkkala
> ---
> src/modules/alsa/alsa-ucm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/modules/alsa/alsa-ucm.c b/src/modules/alsa/alsa-ucm.c
> index 1dfb0e08b..295286555 100644
> --- a/src/modules/alsa/alsa-ucm.c
> +++ b/src/modules/alsa/alsa-ucm.c
> @@ -942,7 +942,7 @@ static void probe_volumes(pa_hashmap *hash, bool is_sink,
> snd_pcm_t *pcm_handle,
> mdev = mdev2;
> }
>
> -if (!(mixer_handle = pa_alsa_open_mixer_by_name(mixers, mdev,
> true))) {
> +if (mdev == NULL || !(mixer_handle =
> pa_alsa_open_mixer_by_name(mixers, mdev, true))) {
> pa_log_error("Failed to find a working mixer device (%s).",
> mdev);
> goto fail;
> }
Thanks! I merged this, and fixed another NULL pointer issue in the same
function.
Note that all patches must go through GitLab merge requests, so patch
submissions through GitLab are preferred.
https://gitlab.freedesktop.org/pulseaudio/pulseaudio
--
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] How to differentiate pause and stop in pulseaudio.
On Mon, 2020-06-15 at 09:15 +, Ramachandra Rao, Arun Kumar wrote: > Hi Team, > > > We have implemented a pulsemodule which listens on > sink_input_new_hook and establishes connection with AudioManager and > based on response from AudioManager, it sends PA_HOOK_OK or > PA_HOOK_CANCEL. > > > And we trigger Stream event request-cork/request-uncork from the > pulsemodule to the corresponding sink_input, so that it reaches > corresponding client application stream. > > This is working perfectly fine for play and pause use-cases. > > > But, we have also requirement to handle stop uses i,.e client > application should be able to differentiate play/pause/stop events. > > From our current understanding, the only way to notify client > applications is through request-cork and request-uncork on stream > events from server side. > > On client side, those could be mapped like below. > > * request-cork -> PAUSE > * request-uncork -> PLAY/RESUME > * ? -> STOP > > Other possibilities we thought and also experimented to differentiate > Stop from Pause are below: > > 1. Unlink the sinkinput from our pulsemodule side based on > AudioManager policy decision. > * [Concern] - This might lead to ungraceful notification on > client side. > * [Concern] - client application gets PA_STREAM_FAILED, which > is difficult to differentiate whether it is stop or real stream > failure at pulseaudio server side. > 2. We could either add/append custom property in the stream > properties about the state(stop) - So, that the client-application > can read this custom property from the stream and act accordingly. > * [Concern] - Every client-application has to implement this > specific handling in addition to cork/uncork handling. Why is this concern specific to solution 2? Whatever you do, your applications will need to have special handling for your special stop event. > * [Concern] - Still some sort of server-side trigger is > required towards client so that, they could read this custom property > of the stream. When the proplist is updated, clients are notified through the subscription system, unless you're updating the proplist directly rather than using pa_sink_input_set_property() or other standard proplist update functions. > 3. As stream events are actually textual information, we tried to > send 'request-stop' for our use case. And this is transparently > transmitted to applications as stream event. > * This works fine for client applications that uses pulseaudio > api directly. > * [Concern] - This is problematic for applications that use > GStreamer. because, we need to adapt GStreamer plugins for pulseaudio > to handle this custom event 'request-stop'. Again, I don't see how any solution can avoid special code in applications or gstreamer or whatever component is handling the communication with PulseAudio. To me sending a cork-request event with the same system as the request- cork event sounds like the simplest approach. -- 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] ALSA: hda/hdmi: Add Intel silent stream support
On Thu, 2020-06-25 at 09:03 +0200, Takashi Iwai wrote: > On Thu, 25 Jun 2020 02:18:58 +0200, > Arun Raghavan wrote: > > +pulseaudio-discuss for information > > > > On Wed, 24 Jun 2020, at 1:33 PM, Takashi Iwai wrote: > > > On Wed, 24 Jun 2020 19:05:14 +0200, > > > Pierre-Louis Bossart wrote: > > > > > > > > > > > > On 6/24/20 11:43 AM, Takashi Iwai wrote: > > > > > On Wed, 24 Jun 2020 17:33:45 +0200, > > > > > Pierre-Louis Bossart wrote: > > > > > > It also doesn't have a UCM representation > > > > > > so would force the use of amixer and manual configs, or the UCM file > > > > > > would always set the mode. > > > > > > > > > > But people usually use the distro kernels, so the situation is more or > > > > > less equivalent; you'd have to adjust a module option manually if you > > > > > want a different one from the default, and you'd have to be root to > > > > > change it. > > > > > > > > > > So, rather the question is how we should provide the setup of such > > > > > parameter. It's supposed to be a part of power management stuff that > > > > > should be touched by either a smart PM tool or a manual override such > > > > > as runtime PM setup? Or can it be seen as a more casual tuning? > > > > > > > > I am not aware of such tools. The only thing I know is that some of > > > > the HDaudio power settings are already controlled by kernel > > > > parameters, e.g. > > > > > > > > /etc/modprobe.d/audio_powersave.conf > > > > options snd_hda_intel power_save=1 > > > > > > Yes, it's been the primary knob for years to turn on/off the runtime > > > PM for HD-audio and other legacy drivers. This was used by powertop > > > or some other power-aware daemons and tools, to be toggled dynamically > > > per the power cable state or such. > > > > > > And, how the silent stream feature should be seen? > > > Should it be a system-wide root-only setup or adjustable per user? > > > Would it be changed often? Such questions and answers will lead us to > > > the right direction, I hope. > > > > For audio, would UCM not be the appropriate point for a system > > integrator to decide how the audio device should be set up? > > > > This would allow for a choice based on the situation in which the > > device is actually being deployed without users having to muck > > around with module parameters -- maybe someone wants want this > > enabled for an HTPC setup, but not on a desktop connected to a > > monitor. Is UCM really an appropriate place for deciding the setting? The default should be to disable the feature, and if that is done in UCM, how is the user expected to enable it when needed? I'm not aware of an easy way to tweak the UCM configuration (modifying distro-provided files is not good). I don't really get the talk about system integrators. This seems like an end-user setting to me. > Right, that's my concern. Many users with HDMI monitor that is > capable of audio don't use HDMI audio because they don't need it > and/or the output sucks. For them, this feature is superfluous and > harmful from the runtime PM POV. > > If it were provided via UCM, would it be yet another UCM profile like > HDMI+silentstream? This can be confusing, too, I'm afraid. > > From the interface POV, as Kai suggested in another mail, the > analogy to power_save option makes sense. OTOH, power_save is the > knob that is better to be enabled (as long as it works), silent stream > is the feature that is needed only when required. So it comes to the > question which interface is easier to manage. Having a separate UCM "profile" (do you mean a verb or a device?) seems overkill. I think there could be a device-specific variable, like SilentStreamControl, which would indicate that the device supports the silent stream feature. The variable would also point to the mixer control for enabling it. That said, I don't see much need for involving UCM at all. UCM becomes more relevant if we want PulseAudio to provide an API for controlling this feature, but until that happens, just having a mixer control that users can toggle seems sufficient to me. (I'm assuming that ALSA remembers mixer settings between boots. I'm not sure if that's the case, but I have the impression that the alsa-state thingy is universally enabled and implements this.) -- 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
[pulseaudio-discuss] Purpose of ports that represent multiple UCM devices?
Hi, I did some work in PulseAudio's UCM code, and I got frustrated by the "combined port" concept. We spend a lot of effort supporting the case where one port represents multiple UCM devices, but I don't understand why we do that. Do you know some use case for that? I would like to drop the feature altogether. -- 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] PulseAudio run in embedded device
On Thu, 2020-04-30 at 15:48 +0800, l...@sunray.cn wrote: > Hi > > I'm using imx6DL device with the kernel yocto 4.1.15. > > I want to use Qt Sound (based on pulseaudio) to play some audio files. But > > it doesn't work. > > Also I want the PA daemon can start before the user login. > > I add the "auth-anonymous=1" after the "load-module > module-native-protocol-unix" in system.pa > > But when I use the pacmd the check it, it returns :"No PulseAudio daemon > running, or not running as session daemon". pacmd doesn't work with the system mode, but that's not a problem, just use pactl instead. pactl is better than pacmd anyway. > then I use paplay to test it ,it returns nothing whitout any voice.( I have > set all the voice max value in alsamixer). Can you attach the output of "paplay -v test.wav"? If you stop pulseaudio, does "aplay -Dplughw:0,0 test.wav" work? If it doesn't, it's probably an alsa problem. > /*Hi TanuK, I really need your help to solve the problem. I also find your > Patreon but I'm from China so that I can't join to you*/ > /*Or if you have other way can be used in China, I'm happy to sponsor you*/ Well, Liberapay is an alternative to Patreon: https://liberapay.com/tanuk Both Liberapay and Patreon are meant for supporting my general maintaner work, so they are not a way to get me work specifically on your problems. That's consulting work, and unfortunately I don't have time for it (but I may respond to simple questions on the mailing list, like this one). -- 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] Bluetooth HSP and HFP support in pulseaudio
On Tue, 2020-04-28 at 16:12 +0200, Pali Rohár wrote: > On Tuesday 28 April 2020 16:33:01 Tanu Kaskinen wrote: > > On Tue, 2020-04-28 at 13:08 +0200, Pali Rohár wrote: > > > On Tuesday 28 April 2020 13:57:42 Tanu Kaskinen wrote: > > > > Just to chime in on the ofono removal issue: I'm also of the opinion > > > > that removing ofono support is not an option. > > > > > > Well, in this case you have 3 choices: > > > > > > * Fix it yourself or find somebody who will work on it and would maintain > > > this code in future > > > * Try asking ofono community to start cooperate and tell them start > > > working and fixing that pulseaudio ofono code (including future > > > maintenance) > > > * Do not take my now fully working hsphpfd support in pulseaudio and do > > > not implement HSP and HFP profiles properly in pulseaudio at all > > > > > > I'm not going to spend another time with ofono and its buggy audio > > > support, I tried it and it was waste of time, and specially now when > > > ofono community is not interested in cooperation; and I have working > > > better alternative suitable also for supporting other parts (like > > > battery support, input button support, etc...) > > > > > > And... what is the purpose of buggy ofono backend support in pulseaudio, > > > now when I provided better code HSP and HFP profiles? > > > > Last year a Collabora developer made a patch that fixed a crash in the > > oFono backend. I assume their customer is using PulseAudio with oFono, > > so I would also assume that it's not so buggy that it's useless (and > > indeed, Georg reports that it's working fine for him). oFono also > > integrates HFP to the telephony stack, which hsphfpd doesn't do. > > Also there are lot of users for which HFP profile via current ofono > pulseaudio implementation does not work, see tons of bugs in issue > tracker and tons of blames for pulseaudio and its totally broken and > non-working microphone bluetooth support on internet forums. And I > understand it, for majority of people it does not work. > > Really look at reality, bluetooth microphone support in pulseaudio is > worse then poor. And *nobody* did anything in pulseaudio for years. > I was able to implement now everything related to bluetooth audio. That's great, thank you for your work! > Is that Collabora developer going to implement all missing, needed and > broken stuff in next days? Or at least next weeks/months? If not, who > other is going to handle all those bluetooth problems? Or do you think > that everything is working fine and there is no need to do anything with > bluetooth related code? It's not helpful to repeat that the ofono code needs massive changes as a precondition to having a hsphfpd backend without specifying those changes, because it sounds so unlikely to be true. Later in your mail you mentioned that the profile switching needs to be changed from synchronous to asynchronous. Good, now there's something concrete to discuss. > I do not want to disagree that for some people it works, I have no > reason to not trust Georg that it works for him. > > > Even if hsphfpd could do everything that oFono does, it's a new > > project, I'd call it experimental at this stage. I don't want to tell > > users that they have to change their working software stack in order to > > keep old features when updating to a new PulseAudio version. > > > > If oFono is not working for you and you therefore can't test it, then > > don't test it. Fixing existing bugs in oFono isn't your job. Just avoid > > touching the oFono code as much as possible. > > I really cannot implement and use hsphpfd backend coexistence with > current ofono backend. And I cannot implement (asynchronous) support for > profile switching between A2DP, HSP and HFP profile which I did in that > published code with current ofono backend. This profile switching is > required for hsphfpd and it is not possible to implement it without > touching and fixing ofono code. So this was also another reason why I > removed it from my WIP codebase. Ok, so you need to change how profile switching works. Can you abstract away the differences between asynchronous and synchronous profile switching? Like call a different card_set_profile() implementation with ofono (this is just an example). To me it seems that it should be entirely possible to move the old bluez-util.c code to the ofono backend for those parts that cause major problems with adapting the ofono code. In the worst case the whole bluetooth infrastructure and modules need to be duplicated, and I really hope we don't have to go there, but that's still better than removing functionality. -- 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] Bluetooth HSP and HFP support in pulseaudio
On Tue, 2020-04-28 at 13:08 +0200, Pali Rohár wrote: > On Tuesday 28 April 2020 13:57:42 Tanu Kaskinen wrote: > > Just to chime in on the ofono removal issue: I'm also of the opinion > > that removing ofono support is not an option. > > Well, in this case you have 3 choices: > > * Fix it yourself or find somebody who will work on it and would maintain > this code in future > * Try asking ofono community to start cooperate and tell them start > working and fixing that pulseaudio ofono code (including future maintenance) > * Do not take my now fully working hsphpfd support in pulseaudio and do not > implement HSP and HFP profiles properly in pulseaudio at all > > I'm not going to spend another time with ofono and its buggy audio > support, I tried it and it was waste of time, and specially now when > ofono community is not interested in cooperation; and I have working > better alternative suitable also for supporting other parts (like > battery support, input button support, etc...) > > And... what is the purpose of buggy ofono backend support in pulseaudio, > now when I provided better code HSP and HFP profiles? Last year a Collabora developer made a patch that fixed a crash in the oFono backend. I assume their customer is using PulseAudio with oFono, so I would also assume that it's not so buggy that it's useless (and indeed, Georg reports that it's working fine for him). oFono also integrates HFP to the telephony stack, which hsphfpd doesn't do. Even if hsphfpd could do everything that oFono does, it's a new project, I'd call it experimental at this stage. I don't want to tell users that they have to change their working software stack in order to keep old features when updating to a new PulseAudio version. If oFono is not working for you and you therefore can't test it, then don't test it. Fixing existing bugs in oFono isn't your job. Just avoid touching the oFono code as much as possible. -- 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] Bluetooth HSP and HFP support in pulseaudio
On Tue, 2020-04-28 at 07:48 +0200, Georg Chini wrote: > On 27.04.20 22:22, Pali Rohár wrote: > > On Monday 27 April 2020 22:18:38 Georg Chini wrote: > > > On 27.04.20 22:12, Pali Rohár wrote: > > > > On Monday 27 April 2020 22:06:29 Georg Chini wrote: > > > > > On 27.04.20 21:45, Georg Chini wrote: > > > > > > On 27.04.20 01:44, Pali Rohár wrote: > > > > > > > On Tuesday 31 March 2020 09:36:21 Georg Chini wrote: > > > > > > > > One comment here: The hsphfpd should be able to co-exist with > > > > > > > > ofono. ofono + PA currently is the only way you can use your > > > > > > > > mobile > > > > > > > > on Linux and we should not break this (unless the hsphfpd > > > > > > > > supplies > > > > > > > > the same functionality). So - similar to ofono - it should at > > > > > > > > least be > > > > > > > > possible to switch off the corresponding role, so that ofono > > > > > > > > can be > > > > > > > > used for one role and hsphfpd for the other. > > > > > > > If you can disable HFP support in ofono, then hsphfpd and ofono > > > > > > > can > > > > > > > coexist in system. > > > > > > > > > > > > > > But coexistence of two HSP AG or HFP AG applications in system is > > > > > > > impossible due to master listening SCO socket. > > > > > > That is exactly my point. But you can have one application handle > > > > > > the > > > > > > AG role while the other handles the HS role. For ofono mainly the HS > > > > > > role is interesting, for PA mainly the AG role. Removing ofono > > > > > > completly > > > > > > makes mobiles unusable under linux. In ofono, you can switch off > > > > > > the AG role. > > > > > You would only need an option so that hsphfpd does not register the HS > > > > > role with bluetoothd and would need to keep the corresponding bits of > > > > > the > > > > > ofono backend. > > > > I can do this in hsphfpd daemon... > > > > > > > > > That should not be much additional work and would not > > > > > break the current use cases of the PA/ofono combination. > > > > ... but I had to remove ofono backend from pulseaudio. Sorry it is > > > > broken and I do not have power to fix ... > > > The HS implementation is not broken but works very well. > > My test results are different. (I spent more days with with this during > > implementation of hsphfpd, integration into pulseaudio and > > interoperability). > > > It works well for me and for other people, so simply removing the > functionality > is not an option in my opinion. If there are issues, they must be fixed, but > that needs not be part of your patch set. Can you be a little bit more > specific > what does not work? Just to chime in on the ofono removal issue: I'm also of the opinion that removing ofono support is not an option. -- 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] Bluetooth codec selection
On Tue, 2020-03-17 at 16:43 +0100, Pali Rohár wrote: > On Tuesday 17 March 2020 11:23:22 Tanu Kaskinen wrote: > > On Sun, 2020-01-12 at 12:42 +0100, Pali Rohár wrote: > > > On Sunday 12 January 2020 09:21:31 Tanu Kaskinen wrote: > > > > Would you be willing to document the codec negotiation process in the > > > > wiki? > > > > > > What exactly? > > > > The things that you mentioned below: > > * Either side can establish the connection, so it's not obvious what > > things can trigger a connection. For example, what might cause a > > headset to initiate the connection? > > * BlueZ may decide the codec instead of PulseAudio. What logic does it > > use? > > * There are many places with their own defaults. What are these places > > and their codec selection logic? > > > > Maybe these things doesn't affect the UI as I first thought, but it > > would be great to have a reference anyway, so that the system can be > > understood when debugging codec issues. > > Ok. So after implementation of multicodec support would be in > pulseaudio I can document how it works and how it can be configured. Thanks! > > > > I can give you a wiki account. I believe you have already > > > > explained this before in emails, but I've forgotten the details. To me > > > > it would make sense if only the playback side (or the audio gateway for > > > > bidirectional modes) could decide the codec, but I recall the reality > > > > is more complicated, and there were multiple places where the chosen > > > > codec may be remembered. > > > > > > Side which establishing connection choose codec. It does not have to be > > > playback side. And connection establishment is done by calling DBus > > > bluez function, independently of pulseaudio (in most cases desktop > > > bluetooth GUI application do that). So we cannot avoid it. > > > > > > But there are many places which has own defaults. So establishing > > > connection would work without specifying codec and some remembered / > > > default value would be used. > > > > > > > The negotiation details affect the constraints > > > > for UI design. > > > > > > We can do this: When user choose profile, then PA issue command to > > > activate profile with some default codec. User would see in GUI what was > > > chosen and could change if is not happy with it. If he does not care > > > about it he would use default / remembered option and so does not have > > > to choose anything. > > > > Here's my current overall thinking: > > > > Having the six profiles as you suggested is good. > > > > If I understood correctly, you're proposing to make the sub-profiles a > > generic concept rather than a bluetooth specific API. I'm a bit > > hesitant to add an abstraction that doesn't in reality abstract > > anything, because bluetooth is the only user for now and other users > > haven't been suggested. On the other hand, I don't foresee concrete > > problems with this either, so I guess it doesn't really matter. > > Ok. If it simplify things, we can decide that subprofile implementation > would be in bluetooth pa module and therefore bluetooth specific. > > Now the remaining question is: Which API or solution would be used to > implement subprofiles (codec selection) by GUI/CLI tools? Pulseaudio > client <--> server protocol would be needed to extended to support this > kind of subprofile commands. Or messaging API (still not merged) could > be used for this. The messaging API fits better if this is bluetooth specific. -- 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] configure a soundcard?
On Mon, 2020-04-13 at 11:02 -0500, Matt Zagrabelny wrote: > Georg, Tanu, and others, > > On Tue, Apr 30, 2019 at 2:35 PM Georg Chini wrote: > > > On 27.04.19 12:26, Tanu Kaskinen wrote: > > > On Fri, 2019-04-26 at 07:37 -0500, Matt Zagrabelny wrote: > > > > On Fri, Apr 26, 2019 at 4:28 AM Tanu Kaskinen wrote: > > > > > > > > > > > In /usr/share/pulseaudio/alsa-mixer/paths/analog-output- > > > headphones.conf, change these lines: > > > > > > [Jack Front Headphone] > > > required-any = any > > > > > > to > > > > > > [Jack Front Headphone] > > > required-any = any > > > state.plugged = unknown > > > state.unplugged = unknown > > > > > > and similarly in /usr/share/pulseaudio/alsa-mixer/paths/analog-output- > > > lineout.conf change these lines: > > > > > > [Jack Line Out Front] > > > required-any = any > > > > > > to > > > > > > [Jack Line Out Front] > > > required-any = any > > > state.plugged = unknown > > > state.unplugged = unknown > > > > > > These changes will be overwritten whenever your distribution updates > > > pulseaudio (yes, this sucks, hopefully this will be improved some day; > > > I think George Chini already has something prepared related to > > > disabling jack detection). > > > > > Yes, once the messaging API patches are merged, I have at > > least patches that provide the basic infrastructure to disable > > jack detection on the fly. > > > > How are the messaging API patches coming along? Slowly moving forward. You can follow the process here: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/51 > I happened to upgrade this computer the other day and was reminded of this > thread. > > Any PA updates for disabling jack detection on the fly? No. -- 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] Device fallback priority
On Sat, 2020-04-11 at 22:29 +0200, Daniel wrote: > Hello, > > I have 2 alsa devices in my system, card 0 is my Nvidia graphics card > for HDMI Audio output, card 1 is my internal onboard audio. I prefer > the HDMI Audio via my Nvidia card and setting this as default device > works just fine. > > When I now add another audio device like via USB or Bluetooth, its > sink becomes default, and this is quite what I want, so this is fine. > But when I now disconnect this device again, the new default sink > always is my internal audio instead of the HDMI audio. > > How can I get the system to fall back to my HDMI Audio after the > active sink gets unavailable? Can I set priorities manually in > default.pa or similar? > > The modules module-default-device-restore, module-device-restore, > module-stream-restore and module-card-restore are loaded. If one of > these is supposed to do this job, does that need some manual > configuration? If yes, how? > > I'm running Ubuntu 19.10 64-bit. I already deleted ~.config/pulse and > restarted pulseaudio to make sure there are no unwanted settings in my > pulse db files. The file .config/pulse/[id]-default-sink correctly > contains the HDMI sink in the format of the output below. > > $ pactl info > Server String: /run/user/1000/pulse/native > Library Protocol Version: 33 > Server Protocol Version: 33 > Is Local: yes > Client Index: 8 > Tile Size: 65472 > User Name: daniel > Host Name: windseeker > Server Name: pulseaudio > Server Version: 13.0 > Default Sample Specification: s16le 2ch 44100Hz > Default Channel Map: front-left,front-right > Default Sink: alsa_output.pci-_01_00.1.hdmi-stereo > Default Source: alsa_output.pci-_01_00.1.hdmi-stereo.monitor > Cookie: b87b:c3cd > > $ pactl list sinks short > 1 alsa_output.pci-_00_1b.0.analog-stereo > module-alsa-card.c s16le 2ch 44100Hz IDLE > 4 alsa_output.pci-_01_00.1.hdmi-stereo > module-alsa-card.c s16le 2ch 44100Hz IDLE If you never use the internal audio, you can switch the card profile to "off" with pavucontrol or pactl. -- 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
[pulseaudio-discuss] New public API: ports sharing jack detection, device types
Hi all, Just a heads-up: there's a discussion ongoing in the Gnome GitLab about new public client API for figuring out which ports share jack detection and for annotating ports with device type information: https://gitlab.gnome.org/GNOME/libgnome-volume-control/-/merge_requests/10 As is the case always with client API additions, it's very desirable to get the API right the first time, because we can't break compatibility later. Therefore I'm inviting input from anyone interested in this topic. The background in short: many laptops have a headset connector that can be used with headphones, headsets or stand-alone microphones, but the hardware can't tell what kind of device was plugged in. Gnome has a pop-up dialog that allows the user to tell what they plugged in, but as new laptops are moving to use UCM, that dialog doesn't work any more. Fixing it properly seems to require changes to the PulseAudio client API. -- 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] Bluetooth codec selection
On Sun, 2020-01-12 at 12:42 +0100, Pali Rohár wrote: > On Sunday 12 January 2020 09:21:31 Tanu Kaskinen wrote: > > On Tue, 2020-01-07 at 19:37 +0100, Pali Rohár wrote: > > > Hello! > > > > > > My A2DP patch series which adds support for more A2DP codecs is still in > > > review state, but Tanu about year ago wrote that do not like my proposal > > > with usage of PA profiles for selecting A2DP codec. Because nobody for > > > last year come up with another option how to solve this problem and > > > because without it is not possible to add support for other codecs it > > > means that pulseaudio is stucked and has no way to improve A2DP support. > > > > > > So here I'm adding another proposal how to handle multi-codec support > > > for bluetooth in pulseaudio. But first description of our problem: > > > > > > Currently we have following profiles for bluetooth card: > > > > > > * headset_audio_gateway > > > * headset_head_unit > > > * a2dp_source > > > * a2dp_sink > > > > > > If we look at HW level of HSP/HFP profiles they may supports following > > > codecs: CVSD, mSBC, AuriStream. All are bidirectional, synchronous. > > > Moreover encoding from PCM stream to codec data may be done at HW level > > > (bluetooth adapter) or on SW level (pulseaudio). Currently encoding to > > > CVSD is done at HW level and encoding to mSBC at SW level. But e.g. new > > > Thinkpads has bluetooth adapters which can do mSBC-encoding at HW level > > > and theoretically pulseaudio could just pass PCM samples to BT without > > > need to use any software sbc encoding library (*). > > > > > > And if we look at A2DP profiles it is quite a bit complicated. Every > > > "A2DP codec" is either one-way (source or sink) or is bi-directional > > > (but it is rare and most devices does not support them). Plus every > > > "A2DP codec" may support more "codec profiles", so e.g. we have SBC-MQ > > > or SBC-HQ. And bidirectional "A2DP codecs" may use different "audio > > > codec" for one directional and different for back directional (e.g. > > > A2DP codec aptX-LL uses aptX codec for playing and SBC codec for > > > recording). > > > > > > Result is: "SBC" codec is supported in "headset_head_unit" PA profile > > > (as mSBC"), it is supported also in "a2dp_sink" PA profile when "A2DP > > > SBC" codec is used and also in "a2dp_source" PA profile when "aptX-LL" > > > codec is used. > > > > > > So adding a new API which sets codec on PA bluetooth card is not enough. > > > > > > I would propose following API: > > > > > > Add support for pulseaudio "sub-profiles". For every pulseaudio profile > > > it would be possible to register sub-profile and applications via > > > pulseaudio API would be able to change sub-profile of some PA card (if > > > currently selected PA profile would support it). > > > > > > Plus adds a two new profiles: > > > * a2dp_source_with_backchannel > > > * a2dp_sink_with_backchannel > > > > > > For music playback in most cases is useful only profiles without > > > backchannel to maximize bandwidth. And because A2DP codecs with > > > bachannel does not fit into HSP profiles it make sense to have them in > > > separate profile. In most cases A2DP profile with backchannel is the > > > best way for VOIP (as it has microphone recording support), so bluetooth > > > policy plugin would be extended to use also this profile for VOIP. > > > > > > Sub-profiles for bluetooth PA card would be following: > > > > > > * headset_audio_gateway > > > - CVSD (hardware) > > > - mSBC (software) > > > - mSBC (hardware) > > > ... > > > * headset_head_unit > > > - same as in headset_audio_gateway > > > * a2dp_source > > > - SBC-LQ > > > - SBC-MQ > > > - SBC-HQ > > > .., > > > - faststream without backchannel > > > - aptX > > > - aptX-HD > > > - aptX-LL without backannel > > > - LDAC > > > ... > > > * a2dp_sink > > > - same as in a2dp_source > > > * a2dp_source_with_backchannel > > > - faststream with backchannel > > > - aptX-LL with backchannel > > > * a2dp_sink_with_backchannel > > > -
Re: [pulseaudio-discuss] Bluetooth HSP and HFP support in pulseaudio
On Sun, 2020-03-15 at 14:37 +0100, Pali Rohár wrote: > Hello! One month passed and I have not answer which solution would > pulseaudio choose for HSP and HFP support. Could you please really look > at my email about state of HSP / HFP support? > > On Saturday 15 February 2020 22:33:10 Pali Rohár wrote: > > If Linux desktop / laptop with pulseaudio want to support HFP profile > > there are following options: > > > > 1) As written above, implement full HFP profile, therefore telephony > >stack in pulseaudio and handle all users features in pulseaudio > >(input devices, power devices, telephony features) including audio > >features (wide band support, custom codec support). In this setup > >pulseaudio would be incompatible with ofono and ofono must be stopped > >on that computer to prevent ofono from taking rfcom socket. > > > > 2) Delegate all non-audio features of HSP and HFP profiles from 1) to > >hsphfpd daemon and implement in pulseaudio only audio related > >features via DBus API provided by hsphfpd daemon. In this setup > >hsphfpd would own rfcom socket and via DBus API would communicate > >with other applications (e.g. pulseaudio, upower). This setup is > >incompatible with ofono, as ofono developers wrote that they do not > >want to use this design and because ofono implements own handling of > >HFP profiles, ofono daemon would need to be stopped on such machine > >to prevent ofono from taking rfcom socket. So telephony functions would > >not be supported until somebody write alternative telephony software > >which would connect to hsphfpd as ofono devs do not want to use > >hsphfpd. > > > > 3) In pulseaudio drop support for all desktop and laptop computers which > >do not have connected cellular modem compatible with ofono. In this > >way we could use ofono's HFP implementation for some basic audio > >stuff. But no additional features (like battery status or input > >buttons) would be provided. Also no custom codecs, etc. > > > > 4) In pulseaudio do not implement proper and full HFP profile support at > >all. Just say to users, that if they want to use bluetooth HFP > >headset, they have to change operating system from Linux to some > >other which implement it. > > > > 5) Like 4) but be silent and do not say anything to users. Do not answer > >to question from users about bluetooth HSP/HFP. Just do not do > >anything. > ... > > So please, pulseaudio developers/maintainers, write what you think and > > which option you choose and who would implement that option. Remember, > > that silence means you automatically chose option 5) which would be rude > > to all pulseaudio users. > > Does really silence mean that option 5) was automatically chosen? I hope > that not. > > If you have not had time to discuss, compare and choose solution, please > write at least that you are not going to choose option 5). I have not had time to discuss. I think it makes sense to try the hsphfpd approach, if you're motivated to write and maintain that all by yourself (plus the integration code in PulseAudio). With luck you'll find someone to help, but I'm not aware of anyone who has time for that. Georg said that it doesn't make sense to implement this only for PA, but if you get it to a working state, I don't see why PipeWire (and maybe alsa-bluez) wouldn't use it too. There's one other approach, however, that you seem to reject for a reason that is not clear to me: if I understood correctly the discussion with the oFono developers[1], they're open to implementing everything hsphfpd does in oFono. They said they're not planning to add the missing features, but they didn't say they would reject patches. For comparison, I'm not really planning to add any features to PulseAudio either (no time for that), but that doesn't mean I reject features implemented by other people than me. Regarding the lack of time to discuss: I'm sorry it took this long to get any input from me. Just staying up to date with everything happening on GitLab, various mailing lists and IRC has taken almost all my time. I have now decided to try allocating 20% of my PulseAudio time for working on your bluetooth stuff. Georg has been in a similar situation as you, so I'll give Georg another 20%, and even though getting the 14.0 release out is supposed to be the highest priority thing, that work hasn't progressed much lately either, so another 20% goes there. Probably the end result is that I won't be able to keep up with the GitLab messages any more, but it's worth trying... [1] I've had to read the oFono discussion on the linux-bluetooth mailing list, because your messages don't get through to the oFono mailing list. Please subscribe to the list if you haven't done so yet (and trim the Cc list, the messages get blocked due to that too), they don't seem pay attention to the mailing list moderation queue. -- Tanu https://www.patreon.com/tanuk
Re: [pulseaudio-discuss] Docs missing for `module-switch-on-port-available`?
On Fri, 2020-03-06 at 14:58 +0200, Leho Kraav wrote: > On Fri, Mar 06, 2020 at 02:56:09PM +0200, Leho Kraav wrote: > > On Fri, Mar 06, 2020 at 10:57:58AM +0200, Tanu Kaskinen wrote: > > > > Tyvm. It is unclear why one should prefer one over the other, in both > > > > directions, what's the specific example use case. > > > > > > > > Can, or should, or shouldn't they be loaded simultaneously? > > Why I even started digging into this was: every time I plug into my > USB-C docks, their internal USB Audio soundcards become the default > sinks. > > Except I don't have anything connected to the dock audio connectors, > which means I would like to have Pulseaudio avoid switching to it. > > It still looks like the feshly minted module-switch-on-connect blacklist > argument might be the thing to aim for? > > I'm not finding any other obvious way to achieve The blacklist can be used for this, yes. But do you actually need module-switch-on-connect? If you have only one sink you want to use, you can remove module-switch-on-connect from the configuration and set the default sink once and it will be remembered. -- 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] Docs missing for `module-switch-on-port-available`?
On Thu, 2020-03-05 at 12:10 +0200, Leho Kraav wrote: > On 5 March 2020 10:46:29 Tanu Kaskinen wrote: > > > On Tue, 2020-03-03 at 22:01 +0200, Leho Kraav wrote: > > > Trying to figure out what exactly is the difference between > > > `module-switch-on-port-available` vs `module-switch-on-connect` > > > > > > But > > > https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Modules/ > > > doesn't list `module-switch-on-port-available` at all. Intentional? > > > > Not intentional. I added now a section for module-switch-on-port- > > available and updated the module-switch-on-connect documentation. Let > > me know if the explanations need improvement. > > Tyvm. It is unclear why one should prefer one over the other, in both > directions, what's the specific example use case. > > Can, or should, or shouldn't they be loaded simultaneously? > > I thought I saw some distro docs say module-switch-on-connect is not loaded > by upstream by default, but no explanation why. Thanks for the feedback! I made some improvements to the docs. -- 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] Docs missing for `module-switch-on-port-available`?
On Tue, 2020-03-03 at 22:01 +0200, Leho Kraav wrote: > Trying to figure out what exactly is the difference between > `module-switch-on-port-available` vs `module-switch-on-connect` > > But > https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Modules/ > doesn't list `module-switch-on-port-available` at all. Intentional? Not intentional. I added now a section for module-switch-on-port- available and updated the module-switch-on-connect documentation. Let me know if the explanations need improvement. -- 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] No sound in one Debian 10 partition (and a debug script)
On Tue, 2020-03-03 at 01:09 -0300, Eduardo Ochs wrote:
> Hi all,
>
> I have two Debian 10 partitions in my laptop, one that was a Debian 9
> that I "apt-get dist-upgrade"d to Debian 10, and one in which Debian
> 10 was installed from scratch using an installation pen drive...
>
> In the "dist-upgrade"d partition sound doesn't work and in the other
> one it does, so let me call them the "bad partition" and the "good
> partition".
>
> I was guessing that the problem was in ALSA, and to test that I wrote
> the script below, ran it in both partitions, and compared their
> outputs:
>
> logthis () { echo $*:; eval $* 2>&1; echo; echo; }
> {
> # Debian version
> logthis cat /etc/issue
> logthis cat /etc/debian_version
> logthis cat /etc/os-release
> logthis lsb_release -da
> logthis hostnamectl
>
> # List devices and PCMs
> logthis aplay -l
> logthis aplay -L
>
> # Drivers and modules
> logthis "lspci -vvv | grep -A8 Audio"
> logthis "lspci -knn | grep -A2 Audio"
>
> # Permissions
> logthis groups
> logthis ls -lAF /proc/asound/
>
> # This partition
> logthis "mount | grep 'on / '"
>
> # ALSA state
> logthis "rm -f /tmp/o; /usr/sbin/alsactl -f /tmp/o store; cat /tmp/o"
>
> } | tee ~/oalsa
>
> then I sent a long e-mail to the ALSA mailing list - this one:
>
> https://www.mail-archive.com/alsa-user@lists.sourceforge.net/msg32698.html
>
> I got two answers. This one, by Kaj Persson, about MANY other sound
> bugs in a dist-upgraded Debian 10,
>
> https://www.mail-archive.com/alsa-user@lists.sourceforge.net/msg32699.html
>
> and another one, very brief, in private - and possibly sent from a
> cell phone -, from Patrick May, saying that he thinks that "aplay -l"
> gives me "Subdevices: 0/1" in the bad partition and "Subdevices: 1/1"
> in the good partition because something - possibly pulseaudio - is
> using one of the subdevices, and that I should try "pulseaudio
> --kill"...
>
> I tried to test Patrick's suggestion, but I found that when I kill a
> pulseaudio process systemd starts a new one, and I spent about two
> hours trying to find a clean way to kill pulseaudio without systemd
> restarting it... I couldn't find a way, and the details overwhelmed
> me, and my brain overheated! Sorry!... =(
>
> If several people are having problems with sound on dist-upgraded
> Debian 10s - note that "several" at this moment means "at least two"!
> - then I think that it would be great to have a much bigger version of
> the script above that would also make pulseaudio report lots of things
> about its status. I can start working on that bigger script, but:
>
> 1) *** ALL HINTS AND SUGGESTIONS ARE WELCOME ***,
>
> 2) again: how do I kill pulseaudio? The most urgent thing now is to
> add a block like this to the script:
>
>logthis my-kill-pulseaudio
>logthis aplay -l
>logthis my-restart-pulseaudio
When PulseAudio is managed by systemd, it's best to use systemctl to
start/stop/restart:
systemctl --user start/stop/restart pulseaudio.service pulseaudio.socket
It's necessary to list both pulseaudio.service and pulseaudio.socket,
because if you only stop the pulseaudio service, it will get
automatically restarted when an application connects to the socket.
When the socket is stopped too, PulseAudio won't restart automatically.
Regarding the "Dummy Output" problem you mentioned on alsa-user, the
usual reason is that something else is using the sound card, so
PulseAudio can't use it. On Debian it's quite often timidity (or at
least has been in the past, I would expect that problem to have been
fixed by now).
You can find out what applications are accessing the sound card with
"lsof /dev/snd/*".
You mentioned that it would be good to have a script that collects
information about PulseAudio status. Such script was added in
PulseAudio 13.0, and can be found here:
https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/blob/master/src/utils/pa-info
--
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] [alsa-devel] Question about the various mixer options in UCM
On Sun, 2020-02-23 at 14:55 +0100, Jaroslav Kysela wrote: > Dne 23. 02. 20 v 10:00 Tanu Kaskinen napsal(a): > > On Sat, 2020-02-22 at 08:53 +0200, Tanu Kaskinen wrote: > > > On Sun, 2020-02-16 at 18:38 +0100, Jaroslav Kysela wrote: > > > > Dne 16. 02. 20 v 11:06 Tanu Kaskinen napsal(a): > > > > > On Sun, 2020-02-16 at 11:42 +0200, Tanu Kaskinen wrote: > > > > > > + pulseaudio-discuss@lists.freedesktop.org > > > > > > > > > > > > On Sat, 2020-02-15 at 17:25 +0100, Jaroslav Kysela wrote: > > > > > > > Actually, I am also trying to resolve the description of the > > > > > > > speaker > > > > > > > configuration. It may not be only enough to give the PCM device, > > > > > > > because we > > > > > > > don't know, if user connected the stereo or surround speakers to > > > > > > > the sound > > > > > > > card output for example. I play with an idea to add device > > > > > > > variants to UCM, > > > > > > > but the question is, how we can map this to pulseaudio > > > > > > > profile/port schematics. > > > > > > > > > > > > > > My quick idea is to export those variants via the verbs, so the > > > > > > > exported verb > > > > > > > names might look like: > > > > > > > > > > > > > > HiFi:Speaker-Stereo > > > > > > > HiFi:Speaker-5.1 > > > > > > > > > > > > > > Where 'HiFi' is the verb name, 'Speaker' is the device name and > > > > > > > 'Stereo' is > > > > > > > the variant name. > > > > > > > > > > > > > > If we need to define multiple variants, all may be exported like: > > > > > > > > > > > > > > HiFi:Speaker-5.1,Mic-4.0 > > > > > > > > > > > > > > Also, we can enhance this and store the configuration to a file, > > > > > > > thus 'HiFi' > > > > > > > can refer to 'HiFi@Speaker-5.1,Mic-4.0' by default. > > > > > > > > > > > > Verb + list-of-device-variants sounds like a good way to map UCM > > > > > > devices to pulseaudio profiles (and if there's just one verb, which > > > > > > I > > > > > > expect to be the common case, don't show it in the profile name). I > > > > > > don't know how the variants should be configured in UCM, but I know > > > > > > that device variants should be able to declare conflicts with other > > > > > > devices (or device variants). For example, 5.1 speaker output may > > > > > > make > > > > > > recording impossible, while stereo speaker output can be used > > > > > > toghether > > > > > > with a mic. If this information is not provided by UCM, pulseaudio > > > > > > will > > > > > > have to probe all variant combinations (like it currently does with > > > > > > the > > > > > > legacy mixer system). > > > > > > > > > > Sorry, now I realized that the Verb + list-of-device-variants scheme > > > > > doesn't really work after all as the profile scheme. Or maybe it does, > > > > > but it's significantly different from what we do currently. Switching > > > > > between Headphones and Speaker-Stereo often doesn't require reopening > > > > > the PCM device, so there's no need for separate Headphones and > > > > > Speaker- > > > > > Stereo profiles. I guess we could still create separate profiles, it > > > > > just means that the profile list will get much longer. > > > > > > > > > > We could add a separate optimization step to the profile creation > > > > > process. That is, first create all possible device-variant > > > > > combinations > > > > > as the initial profile list, and then inspect which profiles can be > > > > > merged. Naming the merged profiles becomes a problem, but I imagine > > > > > it's solvable with static rules (e.g. merging Speakers-Stereo and > > > > > Headphones becomes Analog-Stereo), and if necessary the merging can be > > > > > improved gradually over time. > > > > > > &g
Re: [pulseaudio-discuss] [alsa-devel] Question about the various mixer options in UCM
On Sat, 2020-02-22 at 08:53 +0200, Tanu Kaskinen wrote: > On Sun, 2020-02-16 at 18:38 +0100, Jaroslav Kysela wrote: > > Dne 16. 02. 20 v 11:06 Tanu Kaskinen napsal(a): > > > On Sun, 2020-02-16 at 11:42 +0200, Tanu Kaskinen wrote: > > > > + pulseaudio-discuss@lists.freedesktop.org > > > > > > > > On Sat, 2020-02-15 at 17:25 +0100, Jaroslav Kysela wrote: > > > > > Actually, I am also trying to resolve the description of the speaker > > > > > configuration. It may not be only enough to give the PCM device, > > > > > because we > > > > > don't know, if user connected the stereo or surround speakers to the > > > > > sound > > > > > card output for example. I play with an idea to add device variants > > > > > to UCM, > > > > > but the question is, how we can map this to pulseaudio profile/port > > > > > schematics. > > > > > > > > > > My quick idea is to export those variants via the verbs, so the > > > > > exported verb > > > > > names might look like: > > > > > > > > > > HiFi:Speaker-Stereo > > > > > HiFi:Speaker-5.1 > > > > > > > > > > Where 'HiFi' is the verb name, 'Speaker' is the device name and > > > > > 'Stereo' is > > > > > the variant name. > > > > > > > > > > If we need to define multiple variants, all may be exported like: > > > > > > > > > > HiFi:Speaker-5.1,Mic-4.0 > > > > > > > > > > Also, we can enhance this and store the configuration to a file, thus > > > > > 'HiFi' > > > > > can refer to 'HiFi@Speaker-5.1,Mic-4.0' by default. > > > > > > > > Verb + list-of-device-variants sounds like a good way to map UCM > > > > devices to pulseaudio profiles (and if there's just one verb, which I > > > > expect to be the common case, don't show it in the profile name). I > > > > don't know how the variants should be configured in UCM, but I know > > > > that device variants should be able to declare conflicts with other > > > > devices (or device variants). For example, 5.1 speaker output may make > > > > recording impossible, while stereo speaker output can be used toghether > > > > with a mic. If this information is not provided by UCM, pulseaudio will > > > > have to probe all variant combinations (like it currently does with the > > > > legacy mixer system). > > > > > > Sorry, now I realized that the Verb + list-of-device-variants scheme > > > doesn't really work after all as the profile scheme. Or maybe it does, > > > but it's significantly different from what we do currently. Switching > > > between Headphones and Speaker-Stereo often doesn't require reopening > > > the PCM device, so there's no need for separate Headphones and Speaker- > > > Stereo profiles. I guess we could still create separate profiles, it > > > just means that the profile list will get much longer. > > > > > > We could add a separate optimization step to the profile creation > > > process. That is, first create all possible device-variant combinations > > > as the initial profile list, and then inspect which profiles can be > > > merged. Naming the merged profiles becomes a problem, but I imagine > > > it's solvable with static rules (e.g. merging Speakers-Stereo and > > > Headphones becomes Analog-Stereo), and if necessary the merging can be > > > improved gradually over time. > > > > > > > From profile creation perspective the ideal scheme would be not based > > > on UCM devices but on PCM devices and their configuration variants, but > > > I imagine naming would be an even bigger problem with this scheme (how > > > to map PCM device names to sensible user friendly names?). > > > > I think that I didn't explain my idea in detail. The variant verbs may be > > almost identical (thus all devices will be defined) like the "master" one. > > But > > the specific variant configuration will be returned to the application. So > > it > > will differ only in the channel count value for the Speaker device or so. > > The > > PCM device name + PCM parameters check will be fine. I don't think that we > > should modify something on the PA side. PA activates only one verb per > > soundcard now. > > Oh, you want to create variant verbs? Is the idea t
Re: [pulseaudio-discuss] [alsa-devel] Question about the various mixer options in UCM
On Sun, 2020-02-16 at 18:38 +0100, Jaroslav Kysela wrote: > Dne 16. 02. 20 v 11:06 Tanu Kaskinen napsal(a): > > On Sun, 2020-02-16 at 11:42 +0200, Tanu Kaskinen wrote: > > > + pulseaudio-discuss@lists.freedesktop.org > > > > > > On Sat, 2020-02-15 at 17:25 +0100, Jaroslav Kysela wrote: > > > > Dne 15. 02. 20 v 7:29 Tanu Kaskinen napsal(a): > > > > > What's the difference between PlaybackVolume, PlaybackMixerElem and > > > > > PlaybackMasterElem? Other than the obvious difference that > > > > > PlaybackVolume is used only to configure the volume control, whereas > > > > > PlaybackMixerElem and PlaybackMasterElem are used also to configure > > > > > the > > > > > mute control. > > > > > > > > At first, I don't really know if someone uses > > > > PlaybackVolume/PlaybackSwitch. > > > > It was defined for the direct control interface (not the mixer > > > > interface). I > > > > do not think that we should support this. > > > > > > PlaybackVolume/Switch is currently defined for PandaBoard, > > > PandaBoardES, SDP4430 and sof-hda-dsp. Do you mean those definitions > > > should be removed and replaced with PlaybackMixerElem? It seems that > > > PlaybackVolume and PlaybackSwitch don't always match the same simple > > > mixer element (e.g. PandaBoard), so I'm not sure if it's possible to > > > use PlaybackMixerElem with those platforms. > > > > > > As you know, PulseAudio added support for PlaybackVolume recently. > > > Should we remove the support? I'm not against that, if > > > PlaybackMixerElem is the canonical way to control volume. > > > > > > AFAIK CRAS is a major user of UCM, are there others? I think the CRAS > > > developers' opinion would be very useful here. > > > > > > > I defined new PlaybackMixerElem to select the simple mixer element which > > > > controls both volume and switch (mute) in the ALSA API. The master > > > > volume > > > > might be also in the chain (thus PlaybackMasterElem) was introduced. > > > > > > > > It seems that it might be not enough and I play with an idea to build > > > > custom > > > > mixer description to handle the special cases (like several speakers > > > > with the > > > > different volume controls connected to the single stereo stream etc.). > > > > > > > > To keep things simple, I would probably hide all functionality to > > > > PlaybackMixer/PlaybackMixerElem and CaptureMixer/CaptureMixerElem . The > > > > special mixer name will create the abstract mixer for the applications > > > > and > > > > only one simple mixer element control will set the appropriate volume > > > > for > > > > the stream (like pulseaudio actually does for the legacy ALSA support - > > > > volume > > > > synthetizer). So UCM will describe the mixer for alsa-lib and > > > > application will > > > > use only abstract interface to set / get the volume and mute state. > > > > > > Hiding everything behind an abstract mixer element sounds VERY good, > > > but how to handle a situation where the application uses two devices at > > > the same time and the devices share a volume control? For example, a > > > phone playing a ringtone to both headphones and speakers. If the > > > headphone output has its own abstract mixer element and the speaker > > > output has its own abstract mixer element, the application may imagine > > > that it can change the volumes independently, but if the outputs share > > > a master volume control that is used by both abstract volume elements, > > > the volumes aren't really independent, and the resulting volumes may > > > not be what the application intended. > > This is something which should UCM take in the account. In this case, the > "common" parts should be probably set to a maximum value (or the safe maximum > value) in UCM. Another way is to mark those devices as "conflicting", thus > the > I/O won't be used simultaneously. Hmm, in my example I assumed (but I didn't say) that the headphones and speaker use the same PCM device. In this case the devices will be marked as conflicting anyway, which I didn't take into account, so if an application nevertheless wants to use both outputs, there needs to be a separate headphones+speaker device, which can set up the volume control in a sensible way. The application
Re: [pulseaudio-discuss] [alsa-devel] Question about the various mixer options in UCM
On Sun, 2020-02-16 at 11:42 +0200, Tanu Kaskinen wrote: > + pulseaudio-discuss@lists.freedesktop.org > > On Sat, 2020-02-15 at 17:25 +0100, Jaroslav Kysela wrote: > > Dne 15. 02. 20 v 7:29 Tanu Kaskinen napsal(a): > > > What's the difference between PlaybackVolume, PlaybackMixerElem and > > > PlaybackMasterElem? Other than the obvious difference that > > > PlaybackVolume is used only to configure the volume control, whereas > > > PlaybackMixerElem and PlaybackMasterElem are used also to configure the > > > mute control. > > > > At first, I don't really know if someone uses > > PlaybackVolume/PlaybackSwitch. > > It was defined for the direct control interface (not the mixer interface). > > I > > do not think that we should support this. > > PlaybackVolume/Switch is currently defined for PandaBoard, > PandaBoardES, SDP4430 and sof-hda-dsp. Do you mean those definitions > should be removed and replaced with PlaybackMixerElem? It seems that > PlaybackVolume and PlaybackSwitch don't always match the same simple > mixer element (e.g. PandaBoard), so I'm not sure if it's possible to > use PlaybackMixerElem with those platforms. > > As you know, PulseAudio added support for PlaybackVolume recently. > Should we remove the support? I'm not against that, if > PlaybackMixerElem is the canonical way to control volume. > > AFAIK CRAS is a major user of UCM, are there others? I think the CRAS > developers' opinion would be very useful here. > > > I defined new PlaybackMixerElem to select the simple mixer element which > > controls both volume and switch (mute) in the ALSA API. The master volume > > might be also in the chain (thus PlaybackMasterElem) was introduced. > > > > It seems that it might be not enough and I play with an idea to build > > custom > > mixer description to handle the special cases (like several speakers with > > the > > different volume controls connected to the single stereo stream etc.). > > > > To keep things simple, I would probably hide all functionality to > > PlaybackMixer/PlaybackMixerElem and CaptureMixer/CaptureMixerElem . The > > special mixer name will create the abstract mixer for the applications and > > only one simple mixer element control will set the appropriate volume for > > the stream (like pulseaudio actually does for the legacy ALSA support - > > volume > > synthetizer). So UCM will describe the mixer for alsa-lib and application > > will > > use only abstract interface to set / get the volume and mute state. > > Hiding everything behind an abstract mixer element sounds VERY good, > but how to handle a situation where the application uses two devices at > the same time and the devices share a volume control? For example, a > phone playing a ringtone to both headphones and speakers. If the > headphone output has its own abstract mixer element and the speaker > output has its own abstract mixer element, the application may imagine > that it can change the volumes independently, but if the outputs share > a master volume control that is used by both abstract volume elements, > the volumes aren't really independent, and the resulting volumes may > not be what the application intended. > > > Actually, I am also trying to resolve the description of the speaker > > configuration. It may not be only enough to give the PCM device, because we > > don't know, if user connected the stereo or surround speakers to the sound > > card output for example. I play with an idea to add device variants to UCM, > > but the question is, how we can map this to pulseaudio profile/port > > schematics. > > > > My quick idea is to export those variants via the verbs, so the exported > > verb > > names might look like: > > > > HiFi:Speaker-Stereo > > HiFi:Speaker-5.1 > > > > Where 'HiFi' is the verb name, 'Speaker' is the device name and 'Stereo' is > > the variant name. > > > > If we need to define multiple variants, all may be exported like: > > > > HiFi:Speaker-5.1,Mic-4.0 > > > > Also, we can enhance this and store the configuration to a file, thus > > 'HiFi' > > can refer to 'HiFi@Speaker-5.1,Mic-4.0' by default. > > Verb + list-of-device-variants sounds like a good way to map UCM > devices to pulseaudio profiles (and if there's just one verb, which I > expect to be the common case, don't show it in the profile name). I > don't know how the variants should be configured in UCM, but I know > that device variants should be able to declare conflicts with other > devices (or device variants). For example, 5.1 spe
Re: [pulseaudio-discuss] [alsa-devel] Question about the various mixer options in UCM
+ pulseaudio-discuss@lists.freedesktop.org On Sat, 2020-02-15 at 17:25 +0100, Jaroslav Kysela wrote: > Dne 15. 02. 20 v 7:29 Tanu Kaskinen napsal(a): > > What's the difference between PlaybackVolume, PlaybackMixerElem and > > PlaybackMasterElem? Other than the obvious difference that > > PlaybackVolume is used only to configure the volume control, whereas > > PlaybackMixerElem and PlaybackMasterElem are used also to configure the > > mute control. > > At first, I don't really know if someone uses PlaybackVolume/PlaybackSwitch. > It was defined for the direct control interface (not the mixer interface). I > do not think that we should support this. PlaybackVolume/Switch is currently defined for PandaBoard, PandaBoardES, SDP4430 and sof-hda-dsp. Do you mean those definitions should be removed and replaced with PlaybackMixerElem? It seems that PlaybackVolume and PlaybackSwitch don't always match the same simple mixer element (e.g. PandaBoard), so I'm not sure if it's possible to use PlaybackMixerElem with those platforms. As you know, PulseAudio added support for PlaybackVolume recently. Should we remove the support? I'm not against that, if PlaybackMixerElem is the canonical way to control volume. AFAIK CRAS is a major user of UCM, are there others? I think the CRAS developers' opinion would be very useful here. > I defined new PlaybackMixerElem to select the simple mixer element which > controls both volume and switch (mute) in the ALSA API. The master volume > might be also in the chain (thus PlaybackMasterElem) was introduced. > > It seems that it might be not enough and I play with an idea to build custom > mixer description to handle the special cases (like several speakers with the > different volume controls connected to the single stereo stream etc.). > > To keep things simple, I would probably hide all functionality to > PlaybackMixer/PlaybackMixerElem and CaptureMixer/CaptureMixerElem . The > special mixer name will create the abstract mixer for the applications and > only one simple mixer element control will set the appropriate volume for > the stream (like pulseaudio actually does for the legacy ALSA support - > volume > synthetizer). So UCM will describe the mixer for alsa-lib and application > will > use only abstract interface to set / get the volume and mute state. Hiding everything behind an abstract mixer element sounds VERY good, but how to handle a situation where the application uses two devices at the same time and the devices share a volume control? For example, a phone playing a ringtone to both headphones and speakers. If the headphone output has its own abstract mixer element and the speaker output has its own abstract mixer element, the application may imagine that it can change the volumes independently, but if the outputs share a master volume control that is used by both abstract volume elements, the volumes aren't really independent, and the resulting volumes may not be what the application intended. > Actually, I am also trying to resolve the description of the speaker > configuration. It may not be only enough to give the PCM device, because we > don't know, if user connected the stereo or surround speakers to the sound > card output for example. I play with an idea to add device variants to UCM, > but the question is, how we can map this to pulseaudio profile/port > schematics. > > My quick idea is to export those variants via the verbs, so the exported verb > names might look like: > > HiFi:Speaker-Stereo > HiFi:Speaker-5.1 > > Where 'HiFi' is the verb name, 'Speaker' is the device name and 'Stereo' is > the variant name. > > If we need to define multiple variants, all may be exported like: > > HiFi:Speaker-5.1,Mic-4.0 > > Also, we can enhance this and store the configuration to a file, thus 'HiFi' > can refer to 'HiFi@Speaker-5.1,Mic-4.0' by default. Verb + list-of-device-variants sounds like a good way to map UCM devices to pulseaudio profiles (and if there's just one verb, which I expect to be the common case, don't show it in the profile name). I don't know how the variants should be configured in UCM, but I know that device variants should be able to declare conflicts with other devices (or device variants). For example, 5.1 speaker output may make recording impossible, while stereo speaker output can be used toghether with a mic. If this information is not provided by UCM, pulseaudio will have to probe all variant combinations (like it currently does with the legacy mixer system). -- 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] Custom codec with three channels
On Wed, 2020-01-15 at 18:48 +0100, Matej Kupljen wrote: > Hi all, > > I have an custom embedded board with the i.MX6 SoC which has WM9712 > AC97 codec connected to it. This codec supports 3 channels and has 3 > DACs. Two 16 bit DACs for Left and Right channel and one 12 bit DAC > which can be configured to use one of the AC97 slots. > I have modified the codec driver and the SSI driver for the i.MX6 so I > can use all three channels. > I have selected to use AC97 slot 3 and 4 for Front Left and Front > Right channel and AC97 Slot 5 for this third channel. > > If I use speaker-test utility with: > # speaker-test -t wav -c 3 > > I can hear the sound on all three channels as Front Left, Front Right > and Rear Left. > > Now, I'd like to use pulseaudio server. However, I cannot get a sound > on the third (Rear Left) channel. If I run speaker-test I get the > sound on Front Left and Front right, but not on the third one. > If I run speaker-test with -D hw:0,0 parameter so it directly uses > ALSA driver, I can hear the sound on all three channels. > > I tried adding this configuration options to /etc/pulse/daemon.conf: > default-sample-format = s16le > default-sample-rate = 48000 > default-sample-channels = 3 > default-channel-map = front-left,front-right,rear-left > > Also tried loading alsa module with > module-alsa-sink device=hw:0,0 channel_map=front-left,front-right,rear-left > > But, I cannot get the sound on the third channel. > > Any suggestions how to configure pulseaudio server for this custom set-up? > Is this even possible with my custom set-up? > > Any suggestions/hints would be appreciated. Alsa doesn't allow applications to specify what channel map they use, so the channel map is always the default. For three channels there's no standard channel map, so I checked what channel map speaker-test gets assigned. It gets front-left,front-right,aux0. The aux0 channel won't be played anywhere. You could set your sink channel map to front- left,front-right,aux0 and you'd probably get audio from speaker-test, but you won't get audio from applications that use some other channel map (although no normal application will play three channel audio anyway, so it's unclear to me how you're planning to use the third channel). For testing the third channel, you can try this command: paplay --channel-map=rear-left /usr/share/sounds/alsa/Front_Center.wav Front_Center.wav is a mono file, and the --channel-map argument allows you to tell paplay to play that mono file to a particular channel. -- 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] core, modules: Remove useless EINTR tests
Resurrecting this old patch...
On Mon, 2019-06-03 at 15:43 +0200, Pali Rohár wrote:
> On Tuesday 28 May 2019 16:49:19 Frédéric Danis wrote:
> > Since commit ad447d14682 (in 2009) pa_read and pa_write take care of
> > handling EINTR error.
> > So, pa_read, pa_write, pa_iochannel_read and pa_iochannel_write can not
> > exit with errno set to EINTR, and testing it is useless.
> > ---
> > src/modules/bluetooth/module-bluez5-device.c | 16 +---
> > src/modules/module-esound-sink.c | 4 +-
> > src/modules/module-pipe-sink.c | 17 -
> > src/modules/module-pipe-source.c | 4 +-
> > src/modules/module-solaris.c | 4 +-
> > src/modules/oss/module-oss.c | 10 +
> > src/pulsecore/fdsem.c| 40 ++--
> > src/pulsecore/iochannel.c| 2 +-
> > src/pulsecore/protocol-esound.c | 8 ++--
> > src/pulsecore/protocol-simple.c | 2 +-
> > 10 files changed, 32 insertions(+), 75 deletions(-)
> >
> > diff --git a/src/modules/bluetooth/module-bluez5-device.c
> > b/src/modules/bluetooth/module-bluez5-device.c
> > index 56c96054d..f850a3a41 100644
> > --- a/src/modules/bluetooth/module-bluez5-device.c
> > +++ b/src/modules/bluetooth/module-bluez5-device.c
> > @@ -279,10 +279,6 @@ static int sco_process_render(struct userdata *u) {
> >
> > saved_errno = errno;
> >
> > -if (saved_errno == EINTR)
> > -/* Retry right away if we got interrupted */
> > -continue;
> > -
> > pa_memblock_unref(memchunk.memblock);
> >
> > if (saved_errno == EAGAIN) {
> > @@ -445,11 +441,7 @@ static int a2dp_write_buffer(struct userdata *u,
> > size_t nbytes) {
> >
> > if (l < 0) {
> >
> > -if (errno == EINTR)
> > -/* Retry right away if we got interrupted */
> > -continue;
> > -
> > -else if (errno == EAGAIN) {
> > +if (errno == EAGAIN) {
> > /* Hmm, apparently the socket was not writable, give up
> > for now */
> > pa_log_debug("Got EAGAIN on write() after POLLOUT,
> > probably there is a temporary connection loss.");
> > break;
> > @@ -543,11 +535,7 @@ static int a2dp_process_push(struct userdata *u) {
> >
> > if (l <= 0) {
> >
> > -if (l < 0 && errno == EINTR)
> > -/* Retry right away if we got interrupted */
> > -continue;
> > -
> > -else if (l < 0 && errno == EAGAIN)
> > +if (l < 0 && errno == EAGAIN)
> > /* Hmm, apparently the socket was not readable, give up
> > for now. */
> > break;
> >
>
> Hi! This change conflicts with "Implement reading SO_TIMESTAMP for A2DP
> source" patch as it stops using pa_read() function. For SO_TIMESTAMP is
> needed recvmsg() and then also handling of EINTR/EAGAIN.
Thanks for pointing this out. It would have been easy for me to miss
this, since git rebased the patch without conflicts.
fdsem.c had changes like this:
> @@ -151,11 +151,8 @@ static void flush(pa_fdsem *f) {
> uint64_t u;
>
> if ((r = pa_read(f->efd, , sizeof(u), NULL)) != sizeof(u)) {
> -
> -if (r >= 0 || errno != EINTR) {
> -pa_log_error("Invalid read from eventfd: %s", r < 0 ?
> pa_cstrerror(errno) : "EOF");
> -pa_assert_not_reached();
> -}
> +pa_log_error("Invalid read from eventfd: %s", r < 0 ?
> pa_cstrerror(errno) : "EOF");
> +pa_assert_not_reached();
>
> continue;
The "continue" statement after the assertion is unnecessary, so I
removed it.
I created an MR for this patch, since we now push all changes through
GitLab:
https://gitlab.freedesktop.org/pulseaudio/pulseaudio/merge_requests/238
I didn't merge the change yet, because we're currently in freeze. I'll
merge it once 14.0 is out.
Thanks for the patch, Frédéric, and sorry for the long delay!
--
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] Bluetooth codec selection
On Sun, 2020-01-12 at 09:21 +0200, Tanu Kaskinen wrote: > I'm trying to think this from the user's point of view. The proposed UI > seems to be that first the sub-profile is chosen (activated) and then > the codec parameters can be chosen. I meant "first the profile is chosen", not sub-profile. -- 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] Bluetooth codec selection
On Tue, 2020-01-07 at 19:37 +0100, Pali Rohár wrote: > Hello! > > My A2DP patch series which adds support for more A2DP codecs is still in > review state, but Tanu about year ago wrote that do not like my proposal > with usage of PA profiles for selecting A2DP codec. Because nobody for > last year come up with another option how to solve this problem and > because without it is not possible to add support for other codecs it > means that pulseaudio is stucked and has no way to improve A2DP support. > > So here I'm adding another proposal how to handle multi-codec support > for bluetooth in pulseaudio. But first description of our problem: > > Currently we have following profiles for bluetooth card: > > * headset_audio_gateway > * headset_head_unit > * a2dp_source > * a2dp_sink > > If we look at HW level of HSP/HFP profiles they may supports following > codecs: CVSD, mSBC, AuriStream. All are bidirectional, synchronous. > Moreover encoding from PCM stream to codec data may be done at HW level > (bluetooth adapter) or on SW level (pulseaudio). Currently encoding to > CVSD is done at HW level and encoding to mSBC at SW level. But e.g. new > Thinkpads has bluetooth adapters which can do mSBC-encoding at HW level > and theoretically pulseaudio could just pass PCM samples to BT without > need to use any software sbc encoding library (*). > > And if we look at A2DP profiles it is quite a bit complicated. Every > "A2DP codec" is either one-way (source or sink) or is bi-directional > (but it is rare and most devices does not support them). Plus every > "A2DP codec" may support more "codec profiles", so e.g. we have SBC-MQ > or SBC-HQ. And bidirectional "A2DP codecs" may use different "audio > codec" for one directional and different for back directional (e.g. > A2DP codec aptX-LL uses aptX codec for playing and SBC codec for > recording). > > Result is: "SBC" codec is supported in "headset_head_unit" PA profile > (as mSBC"), it is supported also in "a2dp_sink" PA profile when "A2DP > SBC" codec is used and also in "a2dp_source" PA profile when "aptX-LL" > codec is used. > > So adding a new API which sets codec on PA bluetooth card is not enough. > > I would propose following API: > > Add support for pulseaudio "sub-profiles". For every pulseaudio profile > it would be possible to register sub-profile and applications via > pulseaudio API would be able to change sub-profile of some PA card (if > currently selected PA profile would support it). > > Plus adds a two new profiles: > * a2dp_source_with_backchannel > * a2dp_sink_with_backchannel > > For music playback in most cases is useful only profiles without > backchannel to maximize bandwidth. And because A2DP codecs with > bachannel does not fit into HSP profiles it make sense to have them in > separate profile. In most cases A2DP profile with backchannel is the > best way for VOIP (as it has microphone recording support), so bluetooth > policy plugin would be extended to use also this profile for VOIP. > > Sub-profiles for bluetooth PA card would be following: > > * headset_audio_gateway > - CVSD (hardware) > - mSBC (software) > - mSBC (hardware) > ... > * headset_head_unit > - same as in headset_audio_gateway > * a2dp_source > - SBC-LQ > - SBC-MQ > - SBC-HQ > .., > - faststream without backchannel > - aptX > - aptX-HD > - aptX-LL without backannel > - LDAC > ... > * a2dp_sink > - same as in a2dp_source > * a2dp_source_with_backchannel > - faststream with backchannel > - aptX-LL with backchannel > * a2dp_sink_with_backchannel > - same as in a2dp_source_with_backchannel > > So sub-profile would be one specific configuration of codec. In HSP/HFP > there would be two sub-profiles for every codec (one for software > encoding, one for hardware encoding). In A2DP it may be various. E.g. > for "SBC profiles" there would be one sub-profile for every SBC > configuration. For faststream codec there would be two, one with > backchannel, one without. Default sub-codec selection would be up to > the pulseaudio module. And applications (pactl / pavucontrol / ...) > would be able to change PA sub-profile in similar way how they can do it > for PA profiles. > > Of course some sub-profiles does not have to be supported (e.g. mSBC in > hardware encoding) and in these cases pulseaudio would not announce > these unsupported sub-profiles. > > What do you think about this my proposal? > > Tanu, is this acceptable for you? > > Basically it is needed only to add APIs for applications to: > * get current sub-profile of card > * get list of all sub-profiles for specific profile > * change sub-profile of card > > I'm not saying how would API look like. I'm open for implementation > details... I can imagine that we can extend PA protocol or use messaging > API for it or anything else... > > > (*) - currently Linux kernel blocks this usage of mSBC HW encoding and > force userspace to do whole encoding at application level (in >
Re: [pulseaudio-discuss] Software for switching/managing ports and profiles
On Mon, 2019-12-09 at 11:17 +, Bob Ham wrote: > Hi there, > > I'm working on the Librem 5 phone and we need to be able to manage > PulseAudio ports and profiles, mapped from UCM devices and verbs. So > for example we need to switch from a Handset port to a SpeakerPhone port > when the "Speakerphone" button in the dialer is toggled. Ideally we > also need to do more complex things like prohibit notification sounds > playing when a phone call is active. > > Does anyone know of any existing software for managing PulseAudio ports > and profiles? People certainly have written such software, but I'm not aware of anything that would be easy to adopt. People have generally opted for creating a policy module that interfaces with some external policy daemon. In practice they have forked PulseAudio, becaues there's no stable module API, so the modules need to be built together with PulseAudio (or at least PulseAudio needs to be patched to install the internal headers). Nokia used a policy module + policy daemon with the Maemo and Meego phones, and Sailfish OS inherited that (I don't know if they're still using the same system). Intel created the Murphy policy daemon for automotive IVI systems and that too had an associated PulseAudio module. I think I've seen a custom policy module also in Ubuntu (I don't know if it's used outside their phone distro). -- 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
[pulseaudio-discuss] Freezing master for 14.0
Hi all, It's time to focus on getting 14.0 released, so the master branch will be frozen on Sunday, December 22. Only release blocker bug fixes and translation updates will be accepted after that date. It's possible to convince the maintainers to accept also things that don't fall into those two categories, if it's actually imporant that something is included in 14.0 rather than 15.0. The release blockers are listed here: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/733 The first release candidate will probably be released after all the blockers have been fixed. -- 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 v13 00/10] Bluetooth A2DP codecs
On Wed, 2019-12-11 at 15:44 +0100, Pali Rohár wrote: > Hello! Some of these patches are already reviewed. Can you include these > patches into pulseaudio master git branch? You me this also on IRC, but at the moment you're not on the channel, so I'm responding here: Georg knows better which patches are ready to be merged than me, so I'll let Georg do the merging. I read a few messages, and it seemed that there were still small issues left unresolved. -- 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] librem5 sound
On Fri, 2019-12-06 at 08:51 -0700, Angus Ainslie wrote: > Thanks for the latency suggestions. We added those patches to pulseaudio > 12.2 and it's working well. > > https://source.puri.sm/Librem5/pulseaudio/commit/a5f36231979ea0d4c414a41450d0bc28e25cb817 > > Now I'm trying to map the correct alsa mixer for pulseaudio volume > control. I tried setting PlaybackMixerElem element but it doesn't seem > to be affecting the alsa mixer. > > https://github.com/pulseaudio/pulseaudio/blob/e6779ad229d5858f90f5f10c3796c9778f05c3fa/src/modules/alsa/alsa-ucm.c#L95 > > purism@pureos:~$ amixer -c 1 sget Speaker > Simple mixer control 'Speaker',0 >Capabilities: volume pswitch >Playback channels: Front Left - Front Right >Capture channels: Front Left - Front Right >Limits: 0 - 127 >Front Left: 122 [96%] [1.00dB] Playback [on] >Front Right: 122 [96%] [1.00dB] Playback [off] > > I tried setting it to > > PlaybackMixerElem "name='Speaker Volume'" > > and > > PlaybackMixerElem "Speaker Volume" > > and neither seemed to affect the alsa mixer volume. Am I setting the > wrong ucm_id or am I setting it incorrectly ? The support for hardware volume with UCM landed only yesterday: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/merge_requests/213 You can backport that, or you can disable UCM, either by removing the UCM configuration or by passing "use_ucm=no" to module-udev-detect (or to module-alsa-card if you don't use module-udev-detect). If you're lucky, the default configuration will work, but since this is embedded hardware, it may not follow the usual Intel HDA conventions, in which case you'll need to write some custom configuration. Some documentation is here: https://www.freedesktop.org/wiki/Software/PulseAudio/Backends/ALSA/Profiles/ -- 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] Sound recording/routing issues on Librem5
On Wed, 2019-12-04 at 11:47 -0700, Angus Ainslie wrote: > Hi Tanu, > > On 2019-12-02 08:49, Angus Ainslie wrote: > > Hi Tanu, > > > > On 2019-11-30 12:02, Tanu Kaskinen wrote: > > > On Thu, 2019-11-28 at 16:44 -0700, Angus Ainslie wrote: > > > > Hi, > > > > > > > > The modem sink is passing audio so that's good. The issue with the > > > > sink > > > > is there is about 3 seconds of latency. I can see ~1 second of that > > > > due > > > > to the cellular network. > > > > > > > > How would I check the latency through pulseaudio ? > > > > > > I assume you use module-loopback to route the modem audio to the phone > > > speakers. I use module-loopback to route audio from an electric piano > > > to the computer speakers (actually just USB sound card input to the > > > same card's output), so I can explain how I would check the loopback > > > latency in my case: > > > > > > $ pactl list source-outputs > > > Source Output #11 > > > Driver: module-loopback.c > > > [...] > > > Buffer Latency: 0 usec > > > Source Latency: 0 usec > > > [...] > > > Properties: > > > [...] > > > media.name = "Loopback to PreSonus AudioBox iTwo Analog > > > Stereo" > > > [...] > > > > > > So here we see that I have a recording stream created by module- > > > loopback with zero latency from the source and zero internal latency. > > > > > > $ pactl list sink-inputs > > > Sink Input #959 > > > Driver: module-loopback.c > > > [...] > > > Buffer Latency: 12607 usec > > > Sink Latency: 15778 usec > > > [...] > > > Properties: > > > [...] > > > media.name = "Loopback from PreSonus AudioBox iTwo > > > Analog Stereo" > > > [...] > > > > > > Here we see that I have a playback stream created by module-loopback > > > with 15.8 ms latency from the sink and 12.6 ms internal latency. So > > > far > > > 28.4 ms in total. > > > > > > What these commands don't show is the latency introduced by module- > > > loopback's internal buffer. The fill level of that buffer is not > > > currently shown anywhere. However, the module arguments show what > > > total > > > latency the loopback is trying to achieve: > > > > > > $ pactl list modules > > > Module #41 > > > Name: module-loopback > > > Argument: > > > source=alsa_input.usb-PreSonus_PreSonus_AudioBox_iTwo_AB5C18071273-00.analog-stereo > > > sink=alsa_output.usb-PreSonus_PreSonus_AudioBox_iTwo_AB5C18071273-00.analog-stereo > > > latency_msec=10 adjust_time=0 > > > Usage counter: n/a > > > Properties: > > > module.author = "Pierre-Louis Bossart" > > > module.description = "Loopback from source to sink" > > > module.version = "13.0-8-gd72a3" > > > > > > The module is loaded with argument "latency_msec=10", and that target > > > apparently isn't being met (this is interesting news to me!). 10 ms is > > > probably unnecessarily low target, since I haven't noticed while > > > playing that the piano would have too high latency. In any case, since > > > I care about latency more than avoiding dropouts, I should use the > > > "max_latency_msec" argument instead (new in PulseAudio 13.0). > > > "latency_msec" relaxes the initial target if there are buffer > > > underruns, but "max_latency_msec" sets a hard ceiling for the total > > > latency. > > > > > > I hope this helps. 3 seconds of latency sounds weird, because even if > > > you don't configure any latency with module-loopback, the default > > > latency isn't that high. The latency handling in module-loopback was > > > very bad prior to 11.0, but I hope you're not using that old > > > PulseAudio. > > > > > > Your modem seems to have a fixed latency of 100 ms (maybe you've set > > > tched=0?), which sounds a bit high for something that is used for call > > > audio. > > > > Dropping the alternate rate caused pulse audio to use 48K which > > allowed the sound to flow through the loopbacks and the latency > > disappeared at the same time. > > > > So it
Re: [pulseaudio-discuss] Proposal for a new API and usage of Bluetooth HSP and HFP profiles on Linux
On Sun, 2019-12-01 at 19:57 +0100, Pali Rohár wrote: > Hello! > > I'm sending this email to relevant mailing lists and other people who > could be interested in it. (I'm not subscribed to all of ML, so please > CC me when replying). > > > I would like to open a discussion about a completely new way of handling > Bluetooth HSP and HFP profiles on Linux. These two profiles are the only > standard way how to access microphone data from Bluetooth Headsets. > > > Previously in bluez4, HFP profile was implemented by bluez daemon and > telephony HFP functionality was provided by either dummy modem, ofono > modem or by Nokia's CSD Maemo modem. > > In bluez5 version was modem code together with implementation of HFP > profile removed. And let implementation of HSP and HFP profiles to > external application. > > Currently HSP profile is implemented in pulseaudio daemon to handle > microphone and Bluetooth speakers. HFP profile is not implemented yet. > > > HSP and HFP profiles use AT modem commands, so its implementation needs > to parse and generates AT commands, plus implement needed state machine > for it. > > And now problem is that last version of HFP profile specification is too > complicated, plus Bluetooth headsets vendors started to inventing and > using of own custom extensions to HFP profile and AT commands. > > Main problem of this "external" implementation outside of bluez is that > only one application can communicate with remote Bluetooth device. It > is application which received needed socket from bluez. > > So in this design if audio daemon (pulseaudio) implements HFP profile > for processing audio, and e.g. power supply application wants to > retrieve battery level from Bluetooth device, it means that audio daemon > needs to implement also battery related functionality. > > It does not make sense to force power supply daemon (upower) to > implement audio routing/encoding/decoding or audio daemon (power supply) > to force implementing battery related operations. > > > For handle this problem I would like to propose a new way how to use and > implement HSP and HFP profiles on Linux. > > Implement a new HSP/HFP daemon (I called it hsphfpd) which register HSP > and HFP profiles in bluez and then exports functionality for all other > specific applications via DBus API (API for audio, power supply, input > layer, telephony functions, vendor extensions, etc...). So it would acts > as proxy daemon between bluez and target applications (pulseaudio, > upower, ofono, ...) > > This would simplify whole HFP usage as applications would not need to > re-implement parsing and processing of AT commands and it would allow > more applications to use HFP profile at one time. And also it means that > audio software does not have to implement telephony stack or power > supply operations. > > > I wrote a document how such DBus API could look like, see here: > > https://github.com/pali/hsphfpd-prototype/raw/prototype/hsphfpd.txt > > > And also I implemented "prototype" implementation to verify that > designed API make sense and can be really implemented. Prototype fully > supports HSP profile in both HS and AG role, plus HFP profile in HF > role. This prototype implementation is available here: > > https://github.com/pali/hsphfpd-prototype > > Some other details are written in README: > > https://github.com/pali/hsphfpd-prototype/raw/prototype/README > > > What do you think about it? Does it make sense to have such design? > Would you accept usage of such hsphfpd daemon, implemented according to > specification, on Linux desktop? > > I would like to hear your opinion if I should continue with this hsphfpd > design, or not. > > > With this design and implementation of hsphfpd is possible to easily fix > pulseaudio issue about power supply properties: > > https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/722 I quite like this proposal. Avoiding the need to implement the button press, battery level etc. handling separately in PulseAudio, oFono and PipeWire seems like a pretty good justification to me. I assume you're volunteering to maintain this new daemon? It's not clear to me how this would affect the PulseAudio <-> oFono interaction, if at all. When oFono is used, would PulseAudio get the audio socket from oFono or hsphfpd? What about volume commands, would they go through oFono or would PulseAudio interact with hsphfpd directly? I think hsphfpd should be part of bluetoothd, but if that's not possible, then that's not possible. (I don't want to get into a lengthy discussion about programming languages, but I'll just note here that I don't like Perl.) -- 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] Sound recording/routing issues on Librem5
On Mon, 2019-12-02 at 08:49 -0700, Angus Ainslie wrote: > > So this was a weird one. The modem and codec are fixed at a 48K sample > rate ( the codec can do other rates but the clocks are currently set for > 48k). On the devkit we added an alternate rate of 44.1K to deal with > call audio. Pulse audio was using the alternate rate instead of the > default rate and it was setting up the codec for 44.1K and one of the > rates got set to a sample rate of 47999 Hz > > https://source.puri.sm/Librem5/calls/uploads/c6430c76b6a79aae827291e55305d3ec/after_call.sink-inputs > > In one of the tests I also saw a rate of 43KHz but I don't seem to have > captured any debug for that one. > > Dropping the alternate rate caused pulse audio to use 48K which allowed > the sound to flow through the loopbacks and the latency disappeared at > the same time. > > https://source.puri.sm/angus.ainslie/librem5-base/commit/450976adfacf25da79b71b6dd24a5f8643da0873#dd3464357c7325c6a3167bc6243c1a62926ba401 > > Thanks for your help. Great that you got it behaving! Regarding the weird rates: it's normal that the loopback sink input has a rate that is slightly different from the normal rate. It's part of the logic that adapts to clock drift between the source and sink. If the rate changes a lot, however, that can be an indication that the hardware isn't working properly (it's producing or consuming audio too fast or too slow). -- 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 v13 05/10] bluetooth: Add A2DP aptX and aptX HD codecs support
On Mon, 2019-12-02 at 13:00 +0100, Pali Rohár wrote: > On Sunday 01 December 2019 12:24:07 Georg Chini wrote: > > On 30.11.19 23:39, Pali Rohár wrote: > > > On Saturday 30 November 2019 22:43:47 Georg Chini wrote: > > > > On 06.10.19 19:58, Pali Rohár wrote: > > > > > This patch provides support for aptX and aptX HD codecs in bluetooth > > > > > A2DP > > > > > profile. It uses open source LGPLv2.1+ licensed libopenaptx library > > > > > which > > > > > can be found at https://github.com/pali/libopenaptx. > > > > > > > > > > aptX for s24 stereo samples provides fixed 6:1 compression ratio and > > > > > bitrate 352.8 kbit/s, aptX HD provides fixed 4:1 compression ratio and > > > > > bitrate 529.2 kbit/s. > > > > > > > > > > According to soundexpert research, aptX codec used in bluetooth A2DP > > > > > is no > > > > > better than SBC High Quality settings. And you cannot hear difference > > > > > between aptX and SBC High Quality, aptX is just a copper-less > > > > > overpriced > > > > > audio cable. > > > > > > > > > > aptX HD is high-bitrate version of aptX. It has clearly noticeable > > > > > increase > > > > > in sound quality (not dramatic though taking into account the > > > > > increase in > > > > > bitrate). > > > > > > > > > > http://soundexpert.org/news/-/blogs/audio-quality-of-bluetooth-aptx > > > > One general remark: I would consider passing the a2dp_codec as argument > > > > to the API functions. This way you can avoid having to create one > > > > function > > > > per codec variant. Instead you can use the vendor ID/codec ID or just > > > > the > > > > codec name as a key to a "case" or "if" instruction to distinguish > > > > between > > > > different codec variants. I think especially in the SBC case the code > > > > would > > > > be better readable. In this patch you could avoid duplicating functions > > > > if you can read the vendor and codec ID from the a2dp_codec instead of > > > > hard coding them. > > > I do not think that passing codec structure into every function is a big > > > win. In your suggestion, instead of N functions (one for each codec) you > > > would have just one function with N if-then-else-else-else... branches, > > > one branch for each codec. Currently common parts for all codecs is > > > already in sub-function with suffix _common (so code is not duplicated). > > > > I do not think it would produce less code, but the code would be > > easier to read. > > Now you have to check which codec variant uses which function, > > then you have to check this function for the arguments of the > > common function and then you can look what the common function > > does. > > With passing the codec that could be avoided: All (or at least most) > > codec variants would use the same function > > That is not fully truth. SBC XQ variant needs to check that remote side > supports configuration for SBC XQ. SBC LQ needs to check that remote > side supports configuration for SBC LQ. > > If variants would be same, then one function for checking would be > enough. But they are variants of just because codecs are not same. > > > and you could directly > > see what happens for each variant in this function. Effectively, multiple > > functions would be replaced by if or case instructions as you already > > said, but for me that would be the purpose of the change. > > > > Maybe we should ask Tanu for an opinion? I can live with the current > > approach but would prefer passing the codec. > > Both approaches are (if implemented) correctly should provide equivalent > set of features. So there is no functionality lost when choosing either > my our your implementation variant. > > So maybe Tanu (or somebody else) could give us some comments? If my > currently implemented variant of code API is OK or if Georg's variant > should be used and therefore changing existing code and code in my > patches to it... I'm fine with either. I vote for keeping the current API, since that means less work. -- 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] Sound recording/routing issues on Librem5
On Thu, 2019-11-28 at 16:44 -0700, Angus Ainslie wrote: > Hi, > > On the librem5 phone I'm having problems getting the audio routed from > the modem to the codec. > > The modem source is displaying a couple of odd behaviours. Here are the > modem sources > > index: 0 > name: > driver: > flags: DECIBEL_VOLUME LATENCY > state: SUSPENDED > suspend cause: IDLE > priority: 1000 > volume: front-left: 65536 / 100% / 0.00 dB, front-right: 65536 > / 100% / 0.00 dB > balance 0.00 > base volume: 65536 / 100% / 0.00 dB > volume steps: 65537 > muted: no > current latency: 0.00 ms > max rewind: 0 KiB > sample spec: s16le 2ch 48000Hz > channel map: front-left,front-right > Stereo > used by: 0 > linked by: 0 > fixed latency: 100.00 ms > monitor_of: 0 > card: 0 > module: 6 > properties: > device.description = "Monitor of Built-in Audio Stereo" > device.class = "monitor" > alsa.card = "0" > alsa.card_name = "MODEM" > alsa.long_card_name = "MODEM" > device.bus_path = "platform-sound-wwan" > sysfs.path = "/devices/platform/sound-wwan/sound/card0" > device.form_factor = "internal" > device.string = "0" > module-udev-detect.discovered = "1" > device.icon_name = "audio-card" > index: 1 > name: > driver: > flags: HARDWARE DECIBEL_VOLUME LATENCY > state: SUSPENDED > suspend cause: IDLE > priority: 9000 > volume: front-left: 65536 / 100% / 0.00 dB, front-right: 65536 > / 100% / 0.00 dB > balance 0.00 > base volume: 65536 / 100% / 0.00 dB > volume steps: 65537 > muted: no > current latency: 0.00 ms > max rewind: 0 KiB > sample spec: s16le 2ch 48000Hz > channel map: front-left,front-right > Stereo > used by: 0 > linked by: 1 > fixed latency: 100.00 ms > card: 0 > module: 6 > properties: > alsa.resolution_bits = "16" > device.api = "alsa" > device.class = "sound" > alsa.class = "generic" > alsa.subclass = "generic-mix" > alsa.name = "" > alsa.id = "3003.sai-gtm601 gtm601-0" > alsa.subdevice = "0" > alsa.subdevice_name = "subdevice #0" > alsa.device = "0" > alsa.card = "0" > alsa.card_name = "MODEM" > alsa.long_card_name = "MODEM" > device.bus_path = "platform-sound-wwan" > sysfs.path = "/devices/platform/sound-wwan/sound/card0" > device.form_factor = "internal" > device.string = "hw:0" > device.buffering.buffer_size = "19200" > device.buffering.fragment_size = "4800" > device.access_mode = "mmap" > device.profile.name = "stereo-fallback" > device.profile.description = "Stereo" > device.description = "Built-in Audio Stereo" > module-udev-detect.discovered = "1" > device.icon_name = "audio-card" > ports: > analog-input: Analog Input (priority 1, latency > offset 0 usec, available: unknown) > properties: > > active port: > > If I use parecord to record from alsa_card.platform-sound-wwan I get the > audio from the modem. > > If I use parecord to record from > alsa_output.platform-sound-wwan.stereo-fallback.monitor I don't get any > audio from the call until it disconnects. You apparently solved your routing problem already, but are you aware that that the monitor source captures everything that is played to the "alsa_output.platform-sound-wwan.stereo-fallback" sink, nothing more, nothing less? So if the modem audio isn't playing to the sink, it's expected that there's no audio from the monitor source. > Our application is grabbing the first source from alsa.card_name = > "MODEM" and is showing the same behaviour as parecord. > > Is there a way to disable the monitor source or possibly reorder the > sources ? Why not just fix the source selection logic in your application? Like ignore monitor sources or something. Monitor sources can't be disabled, and sources are listed in the order they are created. > I tried remapping the source and sink but I can't record from that > either. > > load-module module-remap-source source_name=Modem > master=alsa_input.platform-sound-wwan.stereo-fallback >
Re: [pulseaudio-discuss] [PATCH v13 10/10] bluetooth: policy: Treat bi-directional A2DP profiles as suitable for VOIP
On Mon, 2019-10-28 at 17:12 +0100, Hyperion wrote: > - Bluetooth packet size is not constant : BT traffic is splited in radio > slots > that have fixed time lengh : so for a given bandwidth : slots size vary It's still not clear to me whether the bluetooth packets have constant size within one A2DP stream or not. Pali wrote earlier: For established connection, bluetooth packet size is fixed. SBC packet size depends on SBC bitpool (and other) parameters. And because pulseaudio does not support generating fragmented SBC packets, it can only fill those SBC frames which fits into bluetooth packet size. That sounded like reducing the bitpool and therefore the SBC packet size mid-stream wouldn't help, because the lower level bluetooth packet size is constant for the duration of the stream. However, if the bluetooth packet size dynamically reacts to changes in the SBC packet sizes, then reducing the bitpool mid-stream is useful. Can someone confirm which it is? -- 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] PulseAudio is unable to detect correct profile on this system
On Mon, 2019-10-28 at 06:51 +0330, Farhad Mohammadi Majd wrote: > On Sat, 2019-10-26 at 16:26 +0300, Tanu Kaskinen wrote: > > On Sat, 2019-10-26 at 07:57 +0330, Farhad Mohammadi Majd wrote: > > > Hello, I have reported this problem in 2017 August: > > > > > > https://lists.freedesktop.org/archives/pulseaudio-discuss/2017-August/thread.html#28519 > > > > > > Mr. Tanu Kaskinen helped me by providing one way to fix it manually > > > by > > > editing one configuration file: > > > > > > https://lists.freedesktop.org/archives/pulseaudio-discuss/2017-September/thread.html#28607 > > > > > > and he sayd: "[it] is a proper fix that will be included in the > > > next > > > PulseAudio release (if my patch gets approved by then)." > > > > > > I am currently using GNOME 3.34 with PulseAudio 13.0 and this > > > problem > > > is still there! > > > > > > Please read the provided links because *nothing has changed!* and > > > fix > > > this problem in PulseAudio, I am ready to run any command and > > > provide > > > any information that maybe you need it. > > > > > > THANKS > > > > Thanks for the reminder, I applied that patch now. > > > > Thank you again. > > What is the release date of next version of PulseAudio? > Will this patch include in the major next version or minor? > Is there any scheduling for PulseAudio? I would guess the next version will be released in January (slightly optimistic estimate based on past experience of our release process). It will be a major release, I doubt we will have minor releases before that. Since you asked about scheduling, the freeze for 14.0 is scheduled to happen on 2019-12-13. -- 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 v13 10/10] bluetooth: policy: Treat bi-directional A2DP profiles as suitable for VOIP
On Sat, 2019-10-26 at 20:23 +0200, Hyperion wrote: > > 26.10.2019, 14:39, "Tanu Kaskinen" : > > On Sat, 2019-10-19 at 18:42 +0200, Pali Rohár wrote: > > > On Saturday 19 October 2019 19:27:19 Tanu Kaskinen wrote: > > > > On Sat, 2019-10-19 at 18:16 +0200, Pali Rohár wrote: > > > > > On Saturday 19 October 2019 19:07:44 Tanu Kaskinen wrote: > > > > > > On Sat, 2019-10-19 at 17:20 +0200, Pali Rohár wrote: > > > > > > > On Friday 18 October 2019 15:29:43 Tanu Kaskinen wrote: > > > > > > > > On Thu, 2019-10-17 at 15:34 +0200, Hyperion wrote: > > > > > > > > > Regression would mean that some devices can't connect > > > anymore : this > > > > > > > > > won't happen if a workaround is provided, and this > > > workaround won't > > > > > > > > > be used often. > > > > > > > > > > > > > > > > > > Most (99% ?) of the devices will work correctly with my > > > patch (many > > > > > > > > > of them in XQ mode, and some in legacy mode because they > > > will fall > > > > > > > > > back to legacy bitpool during negociation) > > > > > > > > > > > > > > > > > > The remaining (1% ?) : will need a simple boolean swicth in > > > one of > > > > > > > > > the PA config files to restrict negociation to legacy > > > bitpool (a > > > > > > > > > module option ? or daemon.conf ?). > > > > > > > > > > > > > > > > > > I think it's really "simple", efficient, and not dependent > > > of any > > > > > > > > > upcoming Bluez feature. > > > > > > > > > > > > > > > > > > "The complex solution is always the best until one find a > > > simpler one" > > > > > > > > > > > > > > > > I don't know the number of users who use bluetooth headsets > > > with > > > > > > > > PulseAudio, but even just 1% regression rate can mean quite a > > > few > > > > > > > > unhappy users. When your headset suddenly stops working, it's > > > not > > > > > > > > trivial to figure out that you may need to pass a special > > > argument to > > > > > > > > module-bluetooth-discover in order to make it work again. > > > > > > > > > > > > > > > > It would be better to have a module argument to enable the XQ > > > settings. > > > > > > > > > > > > > > Main question, do we really need this special "settings"? > > > Because my > > > > > > > patch series introduce also SBC XQ profile and basically > > > replaces above > > > > > > > module parameter, by runtime configuration. > > > > > > > > > > > > > > For me above solution looks like a hack. It adds some module > > > parameter > > > > > > > for tweaking configuration. And what would happen with that > > > parameter > > > > > > > after we have "proper" support for multiple codecs? Do we need to > > > > > > > maintain backward compatibility? Or would we remove that > > > configuration > > > > > > > and therefore revert to state prior existence of new module > > > parameter > > > > > > > (which is current situation)? > > > > > > > > > > > > After your patches there's still the "automatic bitpool" mode > > > > > > available, right? > > > > > > > > > > Yes, I wanted to have it there for legacy/backward compatibility > > > reasons > > > > > for those devices which could be broken with new settings. That is > > > the > > > > > reason I do not wanted to touch Automatic mode, to have exact same > > > > > behavior as in current (and older) pulseaudio versions. > > > > > > > > > > But if automatic mode is going to be changed, I do not see reason for > > > > > keeping it (the argument for backward compatibility would not apply > > > > > anymore, if it is going to be changed). My patch
Re: [pulseaudio-discuss] [PATCH v13 10/10] bluetooth: policy: Treat bi-directional A2DP profiles as suitable for VOIP
On Sat, 2019-10-26 at 14:54 +0200, Pali Rohár wrote: > On Saturday 26 October 2019 15:39:51 Tanu Kaskinen wrote: > > On Sat, 2019-10-19 at 18:42 +0200, Pali Rohár wrote: > > > On Saturday 19 October 2019 19:27:19 Tanu Kaskinen wrote: > > > > On Sat, 2019-10-19 at 18:16 +0200, Pali Rohár wrote: > > > > > Automatic mode is also main objection against usage of SBC codec (it > > > > > does not specify, say or enforce specific bitrate or quality; it can > > > > > be > > > > > anything) and also reason why there are vendor codecs like aptX. > > > > > Defining SBC LQ, MQ, HQ or XQ just allows to compare it with other > > > > > codecs and guarantee same settings and quality across all devices. > > > > > > > > Doesn't the automatic mode have the benefit that it automatically > > > > adapts to bad radio conditions so that users get the best quality > > > > possible without needing to fiddle with any options in case the initial > > > > bitrate is too high? So it's not entirely pointless. > > > > > > Yes, but it make sense only for lower bitpool values. Higher bitpool > > > increase size of SBC frames and with larger SBC frames there would be > > > lot of wasted space in bluetooth packets as pulseaudio pulseaudio does > > > not support SBC fragmentation. There are only some higher bitpool values > > > which make sense to use. > > > > > > Plus pulseaudio's implementation of (current) automatic mode only > > > decrease bitpool. It never increase it. > > > > > > So yes, it is not pointless, but in current state not very useful for > > > higher bitpool values. > > > > I'm not sure I understand. Why do we care about wasted space in > > bluetooth packets? Do you mean that there are only a few bluetooth > > packet sizes, and decreasing the bitpool doesn't help if the bluetooth > > packet size stays the same? > > Yes. For established connection, bluetooth packet size is fixed. SBC > packet size depends on SBC bitpool (and other) parameters. And because > pulseaudio does not support generating fragmented SBC packets, it can > only fill those SBC frames which fits into bluetooth packet size. If the bluetooth packet size is fixed, doesn't that mean that the bitpool reducing feature is completely useless, since reducing bitpool never reduces the bandwidth requirements? Reducing the bandwidth would require restarting the stream. How is the bluetooth packet size decided? Does the first RTP packet that we write to the stream socket determine the bluetooth packet size? -- 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] PulseAudio is unable to detect correct profile on this system
On Sat, 2019-10-26 at 07:57 +0330, Farhad Mohammadi Majd wrote: > Hello, I have reported this problem in 2017 August: > > https://lists.freedesktop.org/archives/pulseaudio-discuss/2017-August/thread.html#28519 > > Mr. Tanu Kaskinen helped me by providing one way to fix it manually by > editing one configuration file: > > https://lists.freedesktop.org/archives/pulseaudio-discuss/2017-September/thread.html#28607 > > and he sayd: "[it] is a proper fix that will be included in the next > PulseAudio release (if my patch gets approved by then)." > > I am currently using GNOME 3.34 with PulseAudio 13.0 and this problem > is still there! > > Please read the provided links because *nothing has changed!* and fix > this problem in PulseAudio, I am ready to run any command and provide > any information that maybe you need it. > > THANKS Thanks for the reminder, I applied that patch now. -- 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 v13 10/10] bluetooth: policy: Treat bi-directional A2DP profiles as suitable for VOIP
On Sat, 2019-10-19 at 18:42 +0200, Pali Rohár wrote: > On Saturday 19 October 2019 19:27:19 Tanu Kaskinen wrote: > > On Sat, 2019-10-19 at 18:16 +0200, Pali Rohár wrote: > > > On Saturday 19 October 2019 19:07:44 Tanu Kaskinen wrote: > > > > On Sat, 2019-10-19 at 17:20 +0200, Pali Rohár wrote: > > > > > On Friday 18 October 2019 15:29:43 Tanu Kaskinen wrote: > > > > > > On Thu, 2019-10-17 at 15:34 +0200, Hyperion wrote: > > > > > > > Regression would mean that some devices can't connect anymore : > > > > > > > this > > > > > > > won't happen if a workaround is provided, and this workaround > > > > > > > won't > > > > > > > be used often. > > > > > > > > > > > > > > Most (99% ?) of the devices will work correctly with my patch > > > > > > > (many > > > > > > > of them in XQ mode, and some in legacy mode because they will fall > > > > > > > back to legacy bitpool during negociation) > > > > > > > > > > > > > > The remaining (1% ?) : will need a simple boolean swicth in one of > > > > > > > the PA config files to restrict negociation to legacy bitpool (a > > > > > > > module option ? or daemon.conf ?). > > > > > > > > > > > > > > I think it's really "simple", efficient, and not dependent of any > > > > > > > upcoming Bluez feature. > > > > > > > > > > > > > > "The complex solution is always the best until one find a simpler > > > > > > > one" > > > > > > > > > > > > I don't know the number of users who use bluetooth headsets with > > > > > > PulseAudio, but even just 1% regression rate can mean quite a few > > > > > > unhappy users. When your headset suddenly stops working, it's not > > > > > > trivial to figure out that you may need to pass a special argument > > > > > > to > > > > > > module-bluetooth-discover in order to make it work again. > > > > > > > > > > > > It would be better to have a module argument to enable the XQ > > > > > > settings. > > > > > > > > > > Main question, do we really need this special "settings"? Because my > > > > > patch series introduce also SBC XQ profile and basically replaces > > > > > above > > > > > module parameter, by runtime configuration. > > > > > > > > > > For me above solution looks like a hack. It adds some module parameter > > > > > for tweaking configuration. And what would happen with that parameter > > > > > after we have "proper" support for multiple codecs? Do we need to > > > > > maintain backward compatibility? Or would we remove that configuration > > > > > and therefore revert to state prior existence of new module parameter > > > > > (which is current situation)? > > > > > > > > After your patches there's still the "automatic bitpool" mode > > > > available, right? > > > > > > Yes, I wanted to have it there for legacy/backward compatibility reasons > > > for those devices which could be broken with new settings. That is the > > > reason I do not wanted to touch Automatic mode, to have exact same > > > behavior as in current (and older) pulseaudio versions. > > > > > > But if automatic mode is going to be changed, I do not see reason for > > > keeping it (the argument for backward compatibility would not apply > > > anymore, if it is going to be changed). My patch series with new A2DP > > > API can fully replace that automatic mode. > > > > I don't see how the proposed option changes anything about > > compatibility. The option will be disabled by default, so the default > > behaviour will be the same as always. > > And what should happen after support for multiple A2DP codecs (from my > patch series) would be there? Basically it obsoletes that config option. > As all such settings can be set at runtime. If the "enable XQ in the automatic bitpool mode" option is made run- time configurable, then yes, the module argument will become obsolete. Is your point that we should not add the module argument at all, if it will be superseded by a different mechanism? That is, an option to enable
Re: [pulseaudio-discuss] [PATCH v13 10/10] bluetooth: policy: Treat bi-directional A2DP profiles as suitable for VOIP
On Sat, 2019-10-19 at 18:16 +0200, Pali Rohár wrote: > On Saturday 19 October 2019 19:07:44 Tanu Kaskinen wrote: > > On Sat, 2019-10-19 at 17:20 +0200, Pali Rohár wrote: > > > On Friday 18 October 2019 15:29:43 Tanu Kaskinen wrote: > > > > On Thu, 2019-10-17 at 15:34 +0200, Hyperion wrote: > > > > > Regression would mean that some devices can't connect anymore : this > > > > > won't happen if a workaround is provided, and this workaround won't > > > > > be used often. > > > > > > > > > > Most (99% ?) of the devices will work correctly with my patch (many > > > > > of them in XQ mode, and some in legacy mode because they will fall > > > > > back to legacy bitpool during negociation) > > > > > > > > > > The remaining (1% ?) : will need a simple boolean swicth in one of > > > > > the PA config files to restrict negociation to legacy bitpool (a > > > > > module option ? or daemon.conf ?). > > > > > > > > > > I think it's really "simple", efficient, and not dependent of any > > > > > upcoming Bluez feature. > > > > > > > > > > "The complex solution is always the best until one find a simpler one" > > > > > > > > I don't know the number of users who use bluetooth headsets with > > > > PulseAudio, but even just 1% regression rate can mean quite a few > > > > unhappy users. When your headset suddenly stops working, it's not > > > > trivial to figure out that you may need to pass a special argument to > > > > module-bluetooth-discover in order to make it work again. > > > > > > > > It would be better to have a module argument to enable the XQ settings. > > > > > > Main question, do we really need this special "settings"? Because my > > > patch series introduce also SBC XQ profile and basically replaces above > > > module parameter, by runtime configuration. > > > > > > For me above solution looks like a hack. It adds some module parameter > > > for tweaking configuration. And what would happen with that parameter > > > after we have "proper" support for multiple codecs? Do we need to > > > maintain backward compatibility? Or would we remove that configuration > > > and therefore revert to state prior existence of new module parameter > > > (which is current situation)? > > > > After your patches there's still the "automatic bitpool" mode > > available, right? > > Yes, I wanted to have it there for legacy/backward compatibility reasons > for those devices which could be broken with new settings. That is the > reason I do not wanted to touch Automatic mode, to have exact same > behavior as in current (and older) pulseaudio versions. > > But if automatic mode is going to be changed, I do not see reason for > keeping it (the argument for backward compatibility would not apply > anymore, if it is going to be changed). My patch series with new A2DP > API can fully replace that automatic mode. I don't see how the proposed option changes anything about compatibility. The option will be disabled by default, so the default behaviour will be the same as always. > Automatic mode is also main objection against usage of SBC codec (it > does not specify, say or enforce specific bitrate or quality; it can be > anything) and also reason why there are vendor codecs like aptX. > Defining SBC LQ, MQ, HQ or XQ just allows to compare it with other > codecs and guarantee same settings and quality across all devices. Doesn't the automatic mode have the benefit that it automatically adapts to bad radio conditions so that users get the best quality possible without needing to fiddle with any options in case the initial bitrate is too high? So it's not entirely pointless. -- 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 v13 00/10] Bluetooth A2DP codecs
On Thu, 2019-10-17 at 15:45 +0300, Tanu Kaskinen wrote: > On Thu, 2019-10-17 at 12:06 +0200, Pali Rohár wrote: > > Hello! > > > > On Sunday 06 October 2019 19:58:32 Pali Rohár wrote: > > > Changes in v13: > > > * Do not use read smoother for A2DP sink when backchannel is in use > > > * Use new bluez org.freedesktop.DBus.ObjectManager and RegisterApplication > > > DBus APIs for codec switching > > > * Add FastStream codec profile without microphone support > > > * Correctly calculate and fill RTP sequence number in aptX-HD encoded > > > frames > > > > > > Pali Rohár (10): > > > bluetooth: Implement reading SO_TIMESTAMP for A2DP source > > > bluetooth: Print SO_TIMESTAMP warning for SCO source only once > > > bluetooth: Parse remote timestamp from A2DP RTP packets when available > > > bluetooth: Set initial A2DP profile which bluez already activated > > > > May I ask for review at least for these first 4 patches? > > Sure, I'll put you in the queue of people who have requested me to > review their patches. The queue so far: > > 1. Improvements to reconfiguration > https://gitlab.freedesktop.org/pulseaudio/pulseaudio/merge_requests/24 > > 2. Adds SBC XQ negotiated at the best of capabilities of the BT device > https://gitlab.freedesktop.org/pulseaudio/pulseaudio/merge_requests/177 > > 3. alsa-ucm: Support Playback/CaptureVolume > https://gitlab.freedesktop.org/pulseaudio/pulseaudio/merge_requests/32 > > 4. [PATCH v13 00/10] Bluetooth A2DP codecs Update: Georg rightfully complained that I've for a long time promised to review his message API patches, so I put that to the second position in this priority list. Georg said he could review the A2DP codec patches, so that's not blocking on me any more. -- 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 v13 10/10] bluetooth: policy: Treat bi-directional A2DP profiles as suitable for VOIP
On Sat, 2019-10-19 at 17:20 +0200, Pali Rohár wrote: > On Friday 18 October 2019 15:29:43 Tanu Kaskinen wrote: > > On Thu, 2019-10-17 at 15:34 +0200, Hyperion wrote: > > > Regression would mean that some devices can't connect anymore : this > > > won't happen if a workaround is provided, and this workaround won't > > > be used often. > > > > > > Most (99% ?) of the devices will work correctly with my patch (many > > > of them in XQ mode, and some in legacy mode because they will fall > > > back to legacy bitpool during negociation) > > > > > > The remaining (1% ?) : will need a simple boolean swicth in one of > > > the PA config files to restrict negociation to legacy bitpool (a > > > module option ? or daemon.conf ?). > > > > > > I think it's really "simple", efficient, and not dependent of any > > > upcoming Bluez feature. > > > > > > "The complex solution is always the best until one find a simpler one" > > > > I don't know the number of users who use bluetooth headsets with > > PulseAudio, but even just 1% regression rate can mean quite a few > > unhappy users. When your headset suddenly stops working, it's not > > trivial to figure out that you may need to pass a special argument to > > module-bluetooth-discover in order to make it work again. > > > > It would be better to have a module argument to enable the XQ settings. > > Main question, do we really need this special "settings"? Because my > patch series introduce also SBC XQ profile and basically replaces above > module parameter, by runtime configuration. > > For me above solution looks like a hack. It adds some module parameter > for tweaking configuration. And what would happen with that parameter > after we have "proper" support for multiple codecs? Do we need to > maintain backward compatibility? Or would we remove that configuration > and therefore revert to state prior existence of new module parameter > (which is current situation)? After your patches there's still the "automatic bitpool" mode available, right? To me it seems that the new option discussed here would still be useful, if there are users who prefer to use the automatic bitpool mode. -- 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 v13 10/10] bluetooth: policy: Treat bi-directional A2DP profiles as suitable for VOIP
On Fri, 2019-10-18 at 15:01 +0200, Hyperion wrote: > Yes !!! for the module argument ! (just a boolean is needed). > > Which module ? (module-bluez5-device ?). Users load only module-bluetooth-discover, so the module argument has to be added to that module. module-bluetooth-discover in turn loads module-bluez5-discover, and the module argument needs to be added there too. Finally, module-bluez5-discover loads module-bluez5-device, which is the place where the option is actually used. The module argument needs to be added to all three modules. By the way, most technical mailing lists, including this one, prefer the interleaved reply style: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style -- Tanu > JP > > 18.10.2019, 14:52, "Hyperion" : > > That's Why I proposed to set the config switch to "legacy max > > negotiated bitpool" (current code) by default, and let the user > > decide if he/she wants to activate the "XQ max negociated bitpool" > > (my patch). > > > > This way it's less likely to cause regressions than Pali's "forced > > bitpool" XQ modes : by default PA behaves like current version. > > > > And it doesn't rely on future Bluez features. > > > > Jp > > > > 14:29, 18 octobre 2019, "Tanu Kaskinen" : > > > On Thu, 2019-10-17 at 15:34 +0200, Hyperion wrote: > > > > Regression would mean that some devices can't connect anymore : this > > > > won't happen if a workaround is provided, and this workaround won't > > > > be used often. > > > > > > > > Most (99% ?) of the devices will work correctly with my patch (many > > > > of them in XQ mode, and some in legacy mode because they will fall > > > > back to legacy bitpool during negociation) > > > > > > > > The remaining (1% ?) : will need a simple boolean swicth in one of > > > > the PA config files to restrict negociation to legacy bitpool (a > > > > module option ? or daemon.conf ?). > > > > > > > > I think it's really "simple", efficient, and not dependent of any > > > > upcoming Bluez feature. > > > > > > > > "The complex solution is always the best until one find a simpler one" > > > > > > I don't know the number of users who use bluetooth headsets with > > > PulseAudio, but even just 1% regression rate can mean quite a few > > > unhappy users. When your headset suddenly stops working, it's not > > > trivial to figure out that you may need to pass a special argument to > > > module-bluetooth-discover in order to make it work again. > > > > > > It would be better to have a module argument to enable the XQ settings. > > > > > > -- > > > 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 v13 10/10] bluetooth: policy: Treat bi-directional A2DP profiles as suitable for VOIP
On Thu, 2019-10-17 at 15:34 +0200, Hyperion wrote: > Regression would mean that some devices can't connect anymore : this > won't happen if a workaround is provided, and this workaround won't > be used often. > > Most (99% ?) of the devices will work correctly with my patch (many > of them in XQ mode, and some in legacy mode because they will fall > back to legacy bitpool during negociation) > > The remaining (1% ?) : will need a simple boolean swicth in one of > the PA config files to restrict negociation to legacy bitpool (a > module option ? or daemon.conf ?). > > I think it's really "simple", efficient, and not dependent of any > upcoming Bluez feature. > > "The complex solution is always the best until one find a simpler one" I don't know the number of users who use bluetooth headsets with PulseAudio, but even just 1% regression rate can mean quite a few unhappy users. When your headset suddenly stops working, it's not trivial to figure out that you may need to pass a special argument to module-bluetooth-discover in order to make it work again. It would be better to have a module argument to enable the XQ settings. -- 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] Pulseaudio system wide mode design
On Thu, 2019-10-17 at 12:56 +0200, Pali Rohár wrote: > Hello, > > there are repeated problems related to fact that pulseaudio is running > under user session and every user spawns own pulseaudio process. > > Only one process can have exclusive access to specific ALSA card. > > Also only one process can create connection to bluetooth A2DP device. > > Looking at pulseaudio design, which should abstract audio device and > sound cards which are "shared" resources, it looks for me that it is > something which should be managed by (central) point. And not by many, > for every user one. > > So what are the main problems which prevent usage of pulseaudio in > system-wide mode. When in system would be running only instance of > pulseaudio and all users would connect to that one instance? > > I know only problem related to security, that any process which has > access to pulseaudio socket can control audio settings of all other > processes connected to pulseaudio. And also can load or unload any > pulseaudio module. > > But this can be easily fixable by implementing access control, e.g. > users in pulseaudio-admin group would be able to control everything like > before (including module loading) and users in pulseaudio-access group > would be able to see and modify only streams which they created and > would not be able to see other strings (or modify other properties). > And also would not be able to load/unload modules. > > Is there anything else which prevents moving pulseaudio into proper > system wide mode? You say that "this can be easily [fixed] by implementing access control". I would agree, except with the "easily" part. There was an effort to implement access control for supporting sandboxed applications (primarily Flatpak), but that stalled due to lack of reviewers... Wim Taymans was the last one working on it, but he's now building PipeWire (I don't know if there's a cause and effect going on here...). Implementing an access control system isn't that simple. A comment on some of your specific suggestions: if users can only control the streams they created, that sounds very limiting. Users should be able to configure quite freely the hardware that is assigned to the seat that the user is logged in to (surely they should at least be able to control the volume!). And completely disabling module loading isn't ideal either: users should be able to load null sinks or network sinks as they wish, for example. There is need for per-user settings, which I think the system server could very well manage, but all that stuff needs implementation work. I personally think you're probably right that a system daemon would be better than a user daemon, but I have the impression that I'm in the minority here. PipeWire chose the per-user model too, and when I suggested that maybe the system daemon model would be better for the same reasons you mentioned, that didn't get much support. People seem to think that duplicating user management in the audio server when the operating system already does it is ugly and complicated. Improving the system mode in PulseAudio would be welcome (for example, it would be easy to make hotplugging USB and bluetooth cards work even with --disable-module-loading), but if you try to change the design in major ways by adding an access control system, there are no guarantees that the effort will get any further than the last time that was attempted. Maybe it would be better to advocate the system mode to the PipeWire project? It's supposed to some day replace PulseAudio anyway, and it already has a lot of the access control infrastructure, since secure access for sandboxed applications is built in from the beginning. -- 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 v13 10/10] bluetooth: policy: Treat bi-directional A2DP profiles as suitable for VOIP
On Thu, 2019-10-17 at 14:55 +0200, Pali Rohár wrote: > On Thursday 17 October 2019 15:52:00 Tanu Kaskinen wrote: > > On Tue, 2019-10-08 at 18:29 +0200, Pali Rohár wrote: > > > Automatic SBC profile is not going to be changed. It is there to support > > > all devices without any tweaks. ValdikSS already did more tests and > > > there are devices which do not work with higher SBC bitpool. So > > > increasing max value of bitpool in Automatic SBC profile would lead to > > > broken support for these devices and therefore regressions. > > > > > > As Automatic SBC profile is the only one available for systems where > > > codec switching is not supported, it would mean complete regression as > > > these devices completely stops working on those systems. > > > > > > Upgrading either pulseaudio or bluez must not lead to problem that some > > > bluetooth devices stop working (if they worked before upgrade). > > > > > > So no, there would not be any changes in Automatic SBC profile. This one > > > should stay untouched, to make it always working with all existing > > > devices without any regression. > > > > I wasn't aware that advertising the XQ settings during negotiation > > breaks some devices. I guess this means that JP Guillaume's SBC XQ > > patch can't be accepted, assuming that we value avoiding regressions > > more than the improved quality for most headsets? > > In this patch series I'm reworking and proposing also XQ profiles at > separate endpoints. So in case XQ is broken for paricular device, with > codec switching API, user would be able to switch back to automatic SBC > profile (on different SEP) which should stay as it is in current > version, which is working with all devices. Yes, but what about JP Guillaume's patch, which is a simple way of achieving XQ support before your patches have been accepted? I planned to review it first (because he asked), but now it looks like that may not be a good idea (I don't want regressions). > > Here's that patch: > > https://gitlab.freedesktop.org/pulseaudio/pulseaudio/merge_requests/177 > > -- 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 v13 10/10] bluetooth: policy: Treat bi-directional A2DP profiles as suitable for VOIP
On Tue, 2019-10-08 at 18:29 +0200, Pali Rohár wrote: > Automatic SBC profile is not going to be changed. It is there to support > all devices without any tweaks. ValdikSS already did more tests and > there are devices which do not work with higher SBC bitpool. So > increasing max value of bitpool in Automatic SBC profile would lead to > broken support for these devices and therefore regressions. > > As Automatic SBC profile is the only one available for systems where > codec switching is not supported, it would mean complete regression as > these devices completely stops working on those systems. > > Upgrading either pulseaudio or bluez must not lead to problem that some > bluetooth devices stop working (if they worked before upgrade). > > So no, there would not be any changes in Automatic SBC profile. This one > should stay untouched, to make it always working with all existing > devices without any regression. I wasn't aware that advertising the XQ settings during negotiation breaks some devices. I guess this means that JP Guillaume's SBC XQ patch can't be accepted, assuming that we value avoiding regressions more than the improved quality for most headsets? Here's that patch: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/merge_requests/177 -- 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 v13 00/10] Bluetooth A2DP codecs
On Thu, 2019-10-17 at 12:06 +0200, Pali Rohár wrote: > Hello! > > On Sunday 06 October 2019 19:58:32 Pali Rohár wrote: > > Changes in v13: > > * Do not use read smoother for A2DP sink when backchannel is in use > > * Use new bluez org.freedesktop.DBus.ObjectManager and RegisterApplication > > DBus APIs for codec switching > > * Add FastStream codec profile without microphone support > > * Correctly calculate and fill RTP sequence number in aptX-HD encoded frames > > > > Pali Rohár (10): > > bluetooth: Implement reading SO_TIMESTAMP for A2DP source > > bluetooth: Print SO_TIMESTAMP warning for SCO source only once > > bluetooth: Parse remote timestamp from A2DP RTP packets when available > > bluetooth: Set initial A2DP profile which bluez already activated > > May I ask for review at least for these first 4 patches? Sure, I'll put you in the queue of people who have requested me to review their patches. The queue so far: 1. Improvements to reconfiguration https://gitlab.freedesktop.org/pulseaudio/pulseaudio/merge_requests/24 2. Adds SBC XQ negotiated at the best of capabilities of the BT device https://gitlab.freedesktop.org/pulseaudio/pulseaudio/merge_requests/177 3. alsa-ucm: Support Playback/CaptureVolume https://gitlab.freedesktop.org/pulseaudio/pulseaudio/merge_requests/32 4. [PATCH v13 00/10] Bluetooth A2DP codecs -- 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] Create a virtual microphone
On Tue, 2019-09-24 at 10:04 -0500, Andres Santos wrote: > it does fail, > > root@localhost:~# pactl list sources > Connection failure: Connection refused > pa_context_connect() failed: Connection refused That indicates that PulseAudio is not running at all. On a headless server I would recommend running PulseAudio in the system mode, i.e. start it with the --system option as root. -- 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] Create a virtual microphone
On Mon, 2019-09-23 at 12:57 -0500, Andres Santos wrote: > Hello everyone, > > I was wondering if with pulseaudio I could create a virtual microphone to > use, I have a hosted server which obviously doesnt have sound card, and I > would like to stream sound via network to the server and processing using > some python packages, for that my script fails because it looks for the > sound card, and I would only like to setup a virtual microphone to feed my > application, is this possible? Does "pactl list sources" really list nothing? In the default configuration there should at least be a null sink monitor available. -- 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] alsa-mixer-path-test fails on FreeBSD
On Sun, 2019-09-22 at 10:48 -0400, Mikhail T. wrote: > Hello! > > Here is, what I just go trying to build (and test) pulseaudio on > FreeBSD-11.3/amd64 machine: > > FAIL: alsa-mixer-path-test > > > Testsuite summary for pulseaudio 13.0 > > > # TOTAL: 35 > # PASS: 34 > # SKIP: 0 > # XFAIL: 0 > # FAIL: 1 > # XPASS: 0 > # ERROR: 0 > > > See src/test-suite.log > Please report to pulseaudio-discuss (at) lists (dot) freedesktop > (dot) org > > Attaching the logs... Please, advise. Thank you. Yours, I assume that alsa support isn't needed on freebsd, so as a workaround you could disable alsa support. I had a look at the build system, and it seems that it should correctly disable alsa-mixer-path-test when alsa support is disabled. Can you rerun the test with the PULSE_LOG environment variable set to value 9? The test should then print more information that could be helpful in figuring out why the test is failing. -- 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] [ANNOUNCE] PulseAudio 13.0
On Fri, 2019-09-13 at 17:36 +0300, Tanu Kaskinen wrote: > Excellent Friday evening, all! > > I'm not an expert on this, but isn't the number 13 special in some way, > and Friday the 13th as a date especially special? Didn't they have > something to do with luck? They're the universal lucky number and day, > right? If I remember that correctly, then this is a very special > announcement for us superstitious people! Today is the day when > PulseAudio 13.0 has became a thing that exists - may this release bring > great luck to us all! > > This release brings the following changes: > > * Added support for Dolby TrueHD and DTS-HD Master Audio > * Improved initial card profile selection for ALSA cards > * Bluetooth card profile choices aren't persistent any more by default > * Added support for SteelSeries Arctis 5 USB headset > * New "max_latency_msec" module argument for module-loopback > * New "stream_name" module argument for module-rtp-send > * Fixed S/PDIF for CMEDIA USB2.0 High-Speed True HD Audio > * Use source sample spec and channel map by default in module-loopback > * New "avoid_resampling" module argument for module-udev-detect and >module-alsa-card > * "avoid_resampling" also tries to avoid format conversion if the >ALSA device supports it > * New function to enable realtime scheduling for client threads > * Removed BlueZ 4 support > * Dropped intltool > * Introduction of the Meson build system > * Const-ification of parameters across headers > * Minor bug-fixes, bindings updates and several translation updates > > The full release notes have further explanations: > https://www.freedesktop.org/wiki/Software/PulseAudio/Notes/13.0/ It turned out that the release notes were not quite complete yet. I have now added the missing stuff: * Improved 5.1 surround channel routing * Automatically switch away from unavailable card profiles * Removed KDE specific routing configuration * New information collection script for bug reports: pa-info * New "fast_adjust_threshold_msec" module argument for module-loopback * module-role-cork and module-role-ducking can now use recording streams as triggers * Added support for non-PCM formats in module-null-sink * More efficient channel remapping in some cases for 32-bit streams * Removed the "latency_time" option from module-null-source * New convenience functions for getting parameters from pa_format_info * New function for pa_threaded_mainloop to run a callback in the mainloop thread without the mainloop lock being held * New build option for improving build reproducibility More elaborate explanations in the wiki, as always: https://www.freedesktop.org/wiki/Software/PulseAudio/Notes/13.0/ -- 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
[pulseaudio-discuss] [ANNOUNCE] PulseAudio 13.0
Excellent Friday evening, all! I'm not an expert on this, but isn't the number 13 special in some way, and Friday the 13th as a date especially special? Didn't they have something to do with luck? They're the universal lucky number and day, right? If I remember that correctly, then this is a very special announcement for us superstitious people! Today is the day when PulseAudio 13.0 has became a thing that exists - may this release bring great luck to us all! This release brings the following changes: * Added support for Dolby TrueHD and DTS-HD Master Audio * Improved initial card profile selection for ALSA cards * Bluetooth card profile choices aren't persistent any more by default * Added support for SteelSeries Arctis 5 USB headset * New "max_latency_msec" module argument for module-loopback * New "stream_name" module argument for module-rtp-send * Fixed S/PDIF for CMEDIA USB2.0 High-Speed True HD Audio * Use source sample spec and channel map by default in module-loopback * New "avoid_resampling" module argument for module-udev-detect and module-alsa-card * "avoid_resampling" also tries to avoid format conversion if the ALSA device supports it * New function to enable realtime scheduling for client threads * Removed BlueZ 4 support * Dropped intltool * Introduction of the Meson build system * Const-ification of parameters across headers * Minor bug-fixes, bindings updates and several translation updates The full release notes have further explanations: https://www.freedesktop.org/wiki/Software/PulseAudio/Notes/13.0/ Get the fresh tarball here: https://www.freedesktop.org/software/pulseaudio/releases/pulseaudio-13.0.tar.xz SHA256: 961b23ca1acfd28f2bc87414c27bb40e12436efcf2158d29721b1e89f3f28057 Big thanks to all the people who helped by contributing code, translations, bug reports, user support or anything else that I forgot to mention here! -- 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] HDA HDMI audio PCM names
On Tue, 2019-08-27 at 17:39 +0300, Kai Vehmanen wrote: > Hi all, > > we are considering removing the backup-PCM logic from snd_hda_intel > HDMI/DP audio driver (note: this is used for wide variety of HDA > controllers, not just Intel ones). See mail thread on alsa-devel: > > https://mailman.alsa-project.org/pipermail/alsa-devel/2019-August/154561.html > > In short, with DisplayPort-MST, additional monitors connected to a MST > hub, and/or to monitor upstream DP ports, these would be routed to > separate ALSA PCMs, e.g. PCM9 and PCM10, leaving the "standard" PCM > numbers free for non-MST monitors. > > This is getting highly problematic, especially when we support HDMI audio > with systems that have a DSP, and the PCM<->HDMI-audio-converter mapping > can be essentially arbitrary. The proposal is to just expose N pieces > of PCMs (N number of converters in hw, e.g. 3 with i915), and any > connected monitor (MST or not), is roured to one these PCMs. > > Tanu added the ELD autodetect support in PA-12.x, and after that, HDA + PA > works pretty nicely even without the backup PCMs, and a non-standard PCM > device numbering for HDMI audio. > > Now, I'm writing here as some kernel devs have referred to Pulseaudio > as the source for the requirement to map MST monitors to the > backup/virtual PCMs. Can anyone of you recall what was this about? I don't recall, in fact I don't even remember hearing about the "backup PCM" concept before. As far as I can tell, PulseAudio imposes or has imposed the following limitations: * PCMs can't be added and removed dynamically on a card. PulseAudio doesn't have support for dynamic PCMs. * Previously HDMI jack detection required that specific PCM numbers are used, but as you noted, we have autodetection for this now. * The "hdmi:x,y" PCM devices must exist in the alsa configuration, bare "hw:x,z" won't be detected properly. -- 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] Rust binding licensing
On Mon, 2019-08-19 at 22:15 +0100, jnq...@gmail.com wrote: > Hi, > > I don't know if you remember me, but I'm the author of the Rust binding > (https://github.com/jnqnfe/pulse-binding-rust) for PA. > > I am a little uncertain about licensing with regards to my binding, > specifically whether it in any way actually does fall under the concept > of "derived work" and thus is subject to LGPL, or whether it is simply > a copyright matter. > > The things it all hinges upon I suppose is the fact that I've copied > much of the documentation, and since licensing is primarily concerned > with actual code and use of code in compiled form within > binaries/shared-libs/firmwares, I'm just not certain where I stand with > just the documentation aspect and got nowhere googling the topic. > > I have outlined much of what needs to be said regarding licensing wrt. > my Rust binding in the project's main readme ( > https://github.com/jnqnfe/pulse-binding-rust/blob/master/README.md). > > The big issue I have with LGPL is that in the Rust world the default > way "crates" (libraries) are consumed is static compiling (you just > specify the name of a crate as a dependency in your project and it is > just automatically downloaded and compiled in). Many Rust crates are > MIT+Apache licensed, meaning little or no impact regarding the > licensing of the end product they are built into. When it comes to LGPL > crates however, for compliance you must either make the product > GPL/LGPL or else compile the dependent crate (i.e. my binding here) as > a dynamic shared lib. > > Since the default with Rust crates is static compiling, there's great > danger in people just plowing on ahead with using it in non-GPL/LGPL > work, not even realising they're breaking LGPL licensing requirements > (either directly, or indirectly as an inherited dependency from > something else). If they do follow the requirements, building as a > shared lib, then that becomes rather a pain to deal with and an > inefficiency issue, just for a thin binding layer in this case. > > As discussed in the project readme, I leave open the possibility of > using my work under MIT+Apache under strict conditions, while > officially marking it in the crates as LGPL. It would be great though > to resolve the unanswered question. > > If what I have done with copying the documentation *is* covered by the > LGPL such that it *is* a derived work and thus I am forced by default > to also use LGPL, then would you considered granting my project an > exception, specifically just for the aspects that apply, i.e. copying > the documentation? Such that my binding can freely be MIT+Apache > licensed and statically compiled, while not affecting the use of PA > libs themselves of course. The documentation is copyrighted, and since there are no special exceptions mentioned anywhere, it's covered by LGPL like everything else. I now read what the license says, and I got the impression that if you copy the documentation, you have created a derivative work, and the whole work must be licensed under LGPL, and you can't change the licensing terms by adding alternative licenses. Granting an exception for your project probably isn't feasible. The copyrights to PulseAudio code isn't held by any centralized entity. Someone would have to inspect the history of everything you've copied to find out who are the people who hold copyrights to the documentation. Only those who hold the copyrights can grant exceptions. One possibility might be that you split off the documentation to a separate work (probably best to create a separate git repository) so that only the documentation needs to be under LGPL and the bindings themselves you can license however you wish. -- 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] Changing Volume on Streams ( not Sinks )
On Mon, 2019-07-29 at 10:24 -0700, Brian Bulkowski wrote: > Thank you Georg! > > About 12 hours ago I figured it out too. > pa_context_set_sink_input_volume() is the function I was looking for, > and I was mistakenly using pa_context_set_sink_volume_by_index(), an > obvious flaw on my part. > > The other way to get a sink-input id directly from a Stream, you don't > need to list them all and find what you're looking for. That would be > 'pa_stream_get_index'. > > I would suggest adding a single sentence to the doc set --- > > 'pa_stream_get_index' should note that what is returned is a 'sink > input' or 'source output' id, depending on the type of stream. The note > there says "useful for functions such as" which are functions that take > those kinds of IDs, but a little clarity would be helpful. > > If there was a description somewhere in the doc set about the 4 > different id spaces ( more? ), at a higher level, that would be really > great. That finally clicked for me when I was looking at pacmd/pactl and > seeing how that tool lists things, see the different IDs and what you > can do with them. It doesn't really fit in any of the higher level > sections, because it applies to both simple and async and others > > I like PulseAudio quite a bit -- can I give back by trying to write up a > page? By a page, do you mean a new page or section in the doxygen documentation? Yes, documentation patches are very welcome! -- 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 v12 00/13] Bluetooth A2DP codecs
On Sun, 2019-07-21 at 17:07 +0200, Pali Rohár wrote: > On Thursday 18 July 2019 09:12:15 Tanu Kaskinen wrote: > > On Fri, 2019-07-05 at 15:02 +0200, Pali Rohár wrote: > > > Changes in v12: > > > * Renamed SBC UHQ to SBC XQ to match naming convention from > > > > > > http://soundexpert.org/articles/-/blogs/audio-quality-of-sbc-xq-bluetooth-audio-codec > > > * Throw error when PA receive fragmented SBC frame > > > * Log "Couldn't find SO_TIMESTAMP" warning message only once > > > * Update comment for SBC bitpool selection > > > * Add more checks for return values from libsbc > > > * Propagate error value from sbc_reinit() to module-bluez5-device.c > > > * Add checks for SBC frame count > > > * Completely rework/fix MTU, buffer sizes and return values of > > > encode/decode methods > > > > > > Pali Rohár (13): > > > bluetooth: Fix usage of MTU, buffer sizes and return values of > > > encode/decode methods > > > bluetooth: Change A2DP codec API of reset() method to indicate failure > > > bluetooth: Fix usage of RTP structures in SBC codec > > > bluetooth: Implement reading SO_TIMESTAMP for A2DP source > > > bluetooth: Print SO_TIMESTAMP warning for SCO source only once > > > bluetooth: Parse remote timestamp from A2DP RTP packets when available > > > bluetooth: Set initial A2DP profile which bluez already activated > > > bluetooth: Add A2DP aptX and aptX HD codecs support > > > bluetooth: Add A2DP FastStream codec support > > > bluetooth: Add more variants of SBC codec > > > bluetooth: policy: Reflect a2dp profile names > > > bluetooth: Implement A2DP codec switching and backchannel support > > > bluetooth: policy: Treat bi-directional A2DP profiles as suitable for > > > VOIP > > > > > > configure.ac| 36 ++ > > > src/Makefile.am | 8 + > > > src/modules/bluetooth/a2dp-codec-api.h | 14 +- > > > src/modules/bluetooth/a2dp-codec-aptx.c | 448 + > > > src/modules/bluetooth/a2dp-codec-faststream.c | 454 + > > > src/modules/bluetooth/a2dp-codec-sbc.c | 806 > > > +++- > > > src/modules/bluetooth/a2dp-codec-util.c | 26 +- > > > src/modules/bluetooth/bluez5-util.c | 476 +- > > > src/modules/bluetooth/bluez5-util.h | 39 +- > > > src/modules/bluetooth/meson.build | 1 + > > > src/modules/bluetooth/module-bluetooth-policy.c | 127 ++-- > > > src/modules/bluetooth/module-bluez5-device.c| 587 - > > > src/modules/bluetooth/module-bluez5-discover.c | 3 +- > > > src/modules/bluetooth/rtp.h | 58 +- > > > 14 files changed, 2644 insertions(+), 439 deletions(-) > > > create mode 100644 src/modules/bluetooth/a2dp-codec-aptx.c > > > create mode 100644 src/modules/bluetooth/a2dp-codec-faststream.c > > > > Can you fix and resubmit the first three patches? Those are the ones we > > want in the upcoming release. > > I fixed issues which you reported and sent updated first 3 patches. Thanks! I applied them all now. -- 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 v12 00/13] Bluetooth A2DP codecs
On Fri, 2019-07-05 at 15:02 +0200, Pali Rohár wrote: > Changes in v12: > * Renamed SBC UHQ to SBC XQ to match naming convention from > > http://soundexpert.org/articles/-/blogs/audio-quality-of-sbc-xq-bluetooth-audio-codec > * Throw error when PA receive fragmented SBC frame > * Log "Couldn't find SO_TIMESTAMP" warning message only once > * Update comment for SBC bitpool selection > * Add more checks for return values from libsbc > * Propagate error value from sbc_reinit() to module-bluez5-device.c > * Add checks for SBC frame count > * Completely rework/fix MTU, buffer sizes and return values of encode/decode > methods > > Pali Rohár (13): > bluetooth: Fix usage of MTU, buffer sizes and return values of > encode/decode methods > bluetooth: Change A2DP codec API of reset() method to indicate failure > bluetooth: Fix usage of RTP structures in SBC codec > bluetooth: Implement reading SO_TIMESTAMP for A2DP source > bluetooth: Print SO_TIMESTAMP warning for SCO source only once > bluetooth: Parse remote timestamp from A2DP RTP packets when available > bluetooth: Set initial A2DP profile which bluez already activated > bluetooth: Add A2DP aptX and aptX HD codecs support > bluetooth: Add A2DP FastStream codec support > bluetooth: Add more variants of SBC codec > bluetooth: policy: Reflect a2dp profile names > bluetooth: Implement A2DP codec switching and backchannel support > bluetooth: policy: Treat bi-directional A2DP profiles as suitable for > VOIP > > configure.ac| 36 ++ > src/Makefile.am | 8 + > src/modules/bluetooth/a2dp-codec-api.h | 14 +- > src/modules/bluetooth/a2dp-codec-aptx.c | 448 + > src/modules/bluetooth/a2dp-codec-faststream.c | 454 + > src/modules/bluetooth/a2dp-codec-sbc.c | 806 > +++- > src/modules/bluetooth/a2dp-codec-util.c | 26 +- > src/modules/bluetooth/bluez5-util.c | 476 +- > src/modules/bluetooth/bluez5-util.h | 39 +- > src/modules/bluetooth/meson.build | 1 + > src/modules/bluetooth/module-bluetooth-policy.c | 127 ++-- > src/modules/bluetooth/module-bluez5-device.c| 587 - > src/modules/bluetooth/module-bluez5-discover.c | 3 +- > src/modules/bluetooth/rtp.h | 58 +- > 14 files changed, 2644 insertions(+), 439 deletions(-) > create mode 100644 src/modules/bluetooth/a2dp-codec-aptx.c > create mode 100644 src/modules/bluetooth/a2dp-codec-faststream.c Can you fix and resubmit the first three patches? Those are the ones we want in the upcoming release. -- 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 v12 03/13] bluetooth: Fix usage of RTP structures in SBC codec
On Fri, 2019-07-05 at 15:02 +0200, Pali Rohár wrote: > Rename struct rtp_payload to rtp_sbc_payload as it is specific for SBC > codec payload. > > Add proper checks for endianity in rtp.h header and use uint8_t type > where appropriated. > > Field frame_count is only 4 bit number, so add checks to prevent overflow. > > And because is_fragmented field is not parsed by decoder there is no > support for decoding fragmented SBC frames. So throw an error in this case. > --- > src/modules/bluetooth/a2dp-codec-sbc.c | 35 ++-- > src/modules/bluetooth/rtp.h| 58 > +++--- > 2 files changed, 58 insertions(+), 35 deletions(-) Looks good to me. -- 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 v12 02/13] bluetooth: Change A2DP codec API of reset() method to indicate failure
On Fri, 2019-07-05 at 15:02 +0200, Pali Rohár wrote:
> /* Run from I/O thread */
> -static void setup_stream(struct userdata *u) {
> +static bool setup_stream(struct userdata *u) {
> struct pollfd *pollfd;
> int one;
>
> /* return if stream is already set up */
> if (u->stream_setup_done)
> -return;
> +return true;
>
> pa_log_info("Transport %s resuming", u->transport->path);
>
> if (u->profile == PA_BLUETOOTH_PROFILE_A2DP_SINK) {
> pa_assert(u->a2dp_codec);
> -u->a2dp_codec->reset(u->encoder_info);
> +if (u->a2dp_codec->reset(u->encoder_info) != 0)
> +return false;
> } else if (u->profile == PA_BLUETOOTH_PROFILE_A2DP_SOURCE) {
> pa_assert(u->a2dp_codec);
> -u->a2dp_codec->reset(u->decoder_info);
> +if (u->a2dp_codec->reset(u->decoder_info) != 0)
"< 0" is the usual convention rather than "!= 0".
(Sorry for this extra mail, I originally wrote this in the first review
mail, but it seems that before sending it, I trimmed too much from the
bottom of the email and accidentally deleted this bit.)
--
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 v12 02/13] bluetooth: Change A2DP codec API of reset() method to indicate failure
On Fri, 2019-07-05 at 15:02 +0200, Pali Rohár wrote:
> SBC codec reset() method may fail, so propagate this failure to caller.
> ---
> src/modules/bluetooth/a2dp-codec-api.h | 4 ++--
> src/modules/bluetooth/a2dp-codec-sbc.c | 5 +++--
> src/modules/bluetooth/module-bluez5-device.c | 18 --
> 3 files changed, 17 insertions(+), 10 deletions(-)
>
> diff --git a/src/modules/bluetooth/a2dp-codec-api.h
> b/src/modules/bluetooth/a2dp-codec-api.h
> index 881cc659b..bc4844596 100644
> --- a/src/modules/bluetooth/a2dp-codec-api.h
> +++ b/src/modules/bluetooth/a2dp-codec-api.h
> @@ -69,8 +69,8 @@ typedef struct pa_a2dp_codec {
> void *(*init)(bool for_encoding, bool for_backchannel, const uint8_t
> *config_buffer, uint8_t config_size, pa_sample_spec *sample_spec);
> /* Deinitialize and release codec info data in codec_info */
> void (*deinit)(void *codec_info);
> -/* Reset internal state of codec info data in codec_info */
> -void (*reset)(void *codec_info);
> +/* Reset internal state of codec info data in codec_info, returns
> non-zero on failure */
> +int (*reset)(void *codec_info);
>
> /* Get read block size for codec, it is minimal size of buffer
> * needed to decode read_link_mtu bytes of encoded data */
> diff --git a/src/modules/bluetooth/a2dp-codec-sbc.c
> b/src/modules/bluetooth/a2dp-codec-sbc.c
> index e2db91b63..f57c7b01a 100644
> --- a/src/modules/bluetooth/a2dp-codec-sbc.c
> +++ b/src/modules/bluetooth/a2dp-codec-sbc.c
> @@ -466,20 +466,21 @@ static void set_bitpool(struct sbc_info *sbc_info,
> uint8_t bitpool) {
> pa_log_debug("Bitpool has changed to %u", sbc_info->sbc.bitpool);
> }
>
> -static void reset(void *codec_info) {
> +static int reset(void *codec_info) {
> struct sbc_info *sbc_info = (struct sbc_info *) codec_info;
> int ret;
>
> ret = sbc_reinit(_info->sbc, 0);
> if (ret != 0) {
> pa_log_error("SBC reinitialization failed: %d", ret);
> -return;
> +return -1;
> }
>
> /* sbc_reinit() sets also default parameters, so reset them back */
> set_params(sbc_info);
>
> sbc_info->seq_num = 0;
> +return 0;
> }
>
> static size_t get_block_size(void *codec_info, size_t link_mtu) {
> diff --git a/src/modules/bluetooth/module-bluez5-device.c
> b/src/modules/bluetooth/module-bluez5-device.c
> index 140ddb8fb..0b63cd44a 100644
> --- a/src/modules/bluetooth/module-bluez5-device.c
> +++ b/src/modules/bluetooth/module-bluez5-device.c
> @@ -762,22 +762,24 @@ static void transport_config_mtu(struct userdata *u) {
> }
>
> /* Run from I/O thread */
> -static void setup_stream(struct userdata *u) {
> +static bool setup_stream(struct userdata *u) {
Failure should be indicated using a negative int rather than a boolean
value. I see a bool return value for setup_transport_and_stream() has
previously somehow passed review, which is probably why you opted for
bool here, but could you change this anyway?
--
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 v2 7/8] sink: move the streams to the default_sink when the sink is unlinked
On Mon, 2019-07-15 at 21:41 +0200, Georg Chini wrote: > On 15.07.19 14:40, Tanu Kaskinen wrote: > > As for what should be copied from module-rescue-streams to the core - > > the shutdown check is good, but I'm not sure anything else needs to be > > copied. If a sink input can't be moved to the default sink, I think > > it's OK to let it be killed rather than moving it to a sink that is > > neither the default sink nor the sink input's preferred sink. That's > > consistent with the fact that creating a new sink input fails if it > > can't use the default sink. > I don't understand the last sentence. I would prefer to try > to move a sink-input elsewhere when it cannot move to > the default sink, but I am also OK with killing it. When an application creates a stream and doesn't specify a sink, PulseAudio will try to use the default sink. If that doesn't work, the stream creation fails instead of PulseAudio trying to find some other sink that works. To me it would make sense to be consistent in these two cases: creating a new stream and rescuing a stream from a sink that is being removed. If we care so much about keeping a stream alive that killing it is the absolute last resort, then we probably should also try to find a working alternative when the default sink doesn't work for a newly created sink input. However, the simpler solution of just killing the stream seems like an acceptable policy to me. -- 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 v2 4/8] core: move sink-inputs conditionally when update default_sink
On Sat, 2019-07-13 at 11:31 +0200, Georg Chini wrote:
> On 13.07.19 10:46, Georg Chini wrote:
> > On 30.06.19 13:52, Georg Chini wrote:
> > > On 17.01.19 07:53, Hui Wang wrote:
> > > > When the default sink changes, the streams from the old default sink
> > > > should be moved to the new default sink, unless the preferred_sink
> > > > string is set to the old default sink and the active port of the old
> > > > default sink is not unavailable
> > > >
> > > > Signed-off-by: Hui Wang
> > > > ---
> > > > src/modules/dbus/iface-core.c | 2 +-
> > > > src/modules/module-default-device-restore.c | 2 +-
> > > > src/modules/module-switch-on-connect.c | 27 ++--
> > > > src/pulsecore/cli-command.c | 2 +-
> > > > src/pulsecore/core.c| 10 --
> > > > src/pulsecore/core.h| 4 +--
> > > > src/pulsecore/device-port.c | 2 +-
> > > > src/pulsecore/protocol-native.c | 2 +-
> > > > src/pulsecore/sink.c| 35
> > > > +++--
> > > > src/pulsecore/sink.h| 6
> > > > 10 files changed, 54 insertions(+), 38 deletions(-)
> > > >
> > > > diff --git a/src/modules/dbus/iface-core.c
> > > > b/src/modules/dbus/iface-core.c
> > > > index 5229c0467..9763480d2 100644
> > > > --- a/src/modules/dbus/iface-core.c
> > > > +++ b/src/modules/dbus/iface-core.c
> > > > @@ -721,7 +721,7 @@ static void
> > > > handle_set_fallback_sink(DBusConnection *conn, DBusMessage *msg, DBu
> > > > return;
> > > > }
> > > > -pa_core_set_configured_default_sink(c->core,
> > > > pa_dbusiface_device_get_sink(fallback_sink)->name);
> > > > +pa_core_set_configured_default_sink(c->core,
> > > > pa_dbusiface_device_get_sink(fallback_sink)->name, true);
> > > > pa_dbus_send_empty_reply(conn, msg);
> > > > }
> > > > diff --git a/src/modules/module-default-device-restore.c
> > > > b/src/modules/module-default-device-restore.c
> > > > index c4dbad99f..33e74c071 100644
> > > > --- a/src/modules/module-default-device-restore.c
> > > > +++ b/src/modules/module-default-device-restore.c
> > > > @@ -69,7 +69,7 @@ static void load(struct userdata *u) {
> > > > pa_log_warn("Invalid sink name: %s", ln);
> > > > else {
> > > > pa_log_info("Restoring default sink '%s'.", ln);
> > > > -pa_core_set_configured_default_sink(u->core, ln);
> > > > +pa_core_set_configured_default_sink(u->core, ln, false);
> > > > }
> > > > } else if (errno != ENOENT)
> > > > diff --git a/src/modules/module-switch-on-connect.c
> > > > b/src/modules/module-switch-on-connect.c
> > > > index f0cb29a7c..3ceac8b4f 100644
> > > > --- a/src/modules/module-switch-on-connect.c
> > > > +++ b/src/modules/module-switch-on-connect.c
> > > > @@ -54,9 +54,6 @@ struct userdata {
> > > > };
> > > > static pa_hook_result_t sink_put_hook_callback(pa_core *c,
> > > > pa_sink *sink, void* userdata) {
> > > > -pa_sink_input *i;
> > > > -uint32_t idx;
> > > > -pa_sink *old_default_sink;
> > > > const char *s;
> > > > struct userdata *u = userdata;
> > > > @@ -88,7 +85,7 @@ static pa_hook_result_t
> > > > sink_put_hook_callback(pa_core *c, pa_sink *sink, void*
> > > > /* No default sink, nothing to move away, just set the new
> > > > default */
> > > > if (!c->default_sink) {
> > > > -pa_core_set_configured_default_sink(c, sink->name);
> > > > +pa_core_set_configured_default_sink(c, sink->name, false);
> > > > return PA_HOOK_OK;
> > > > }
> > > > @@ -103,28 +100,8 @@ static pa_hook_result_t
> > > > sink_put_hook_callback(pa_core *c, pa_sink *sink, void*
> > > > return PA_HOOK_OK;
> > > > }
> > > > -old_default_sink = c->default_sink;
> > > > -
> > > > /* Actually do the switch to the new sink */
> > > > -pa_core_set_configured_default_sink(c, sink->name);
> > > > -
> > > > -/* Now move all old inputs over */
> > > > -if (pa_idxset_size(old_default_sink->inputs) <= 0) {
> > > > -pa_log_debug("No sink inputs to move away.");
> > > > -return PA_HOOK_OK;
> > > > -}
> > > > -
> > > > -PA_IDXSET_FOREACH(i, old_default_sink->inputs, idx) {
> > > > -if (pa_safe_streq(i->sink->name, i->preferred_sink) ||
> > > > !PA_SINK_INPUT_IS_LINKED(i->state))
> > > > -continue;
> > > > -
> > > > -if (pa_sink_input_move_to(i, sink, false) < 0)
> > > > -pa_log_info("Failed to move sink input %u \"%s\" to
> > > > %s.", i->index,
> > > > - pa_strnull(pa_proplist_gets(i->proplist,
> > > > PA_PROP_APPLICATION_NAME)), sink->name);
> > > > -else
> > > > -pa_log_info("Successfully moved sink input %u \"%s\" to
> > > > %s.", i->index,
> > > > - pa_strnull(pa_proplist_gets(i->proplist,
> > > >
Re: [pulseaudio-discuss] [PATCH v2 7/8] sink: move the streams to the default_sink when the sink is unlinked
On Sat, 2019-07-13 at 11:03 +0200, Georg Chini wrote:
> On 30.06.19 14:15, Georg Chini wrote:
> > On 17.01.19 07:53, Hui Wang wrote:
> > > When a sink is unlinked, all streams of this sink are moved to
> > > default_sink, this action is implemented in the core rather than
> > > modules now.
> > >
> > > Signed-off-by: Hui Wang
> > > ---
> > > src/modules/module-stream-restore.c | 50 -
> > > src/pulsecore/sink.c| 3 ++
> > > 2 files changed, 3 insertions(+), 50 deletions(-)
> > >
> > > diff --git a/src/modules/module-stream-restore.c
> > > b/src/modules/module-stream-restore.c
> > > index c7a5f228a..fd3acb5bd 100644
> > > --- a/src/modules/module-stream-restore.c
> > > +++ b/src/modules/module-stream-restore.c
> > > @@ -96,7 +96,6 @@ struct userdata {
> > > *source_output_new_hook_slot,
> > > *source_output_fixate_hook_slot,
> > > *source_put_hook_slot,
> > > -*sink_unlink_hook_slot,
> > > *source_unlink_hook_slot,
> > > *connection_unlink_hook_slot;
> > > pa_time_event *save_time_event;
> > > @@ -1691,54 +1690,6 @@ static pa_hook_result_t
> > > source_put_hook_callback(pa_core *c, pa_source *source,
> > > return PA_HOOK_OK;
> > > }
> > > -static pa_hook_result_t sink_unlink_hook_callback(pa_core *c,
> > > pa_sink *sink, struct userdata *u) {
> > > -pa_sink_input *si;
> > > -uint32_t idx;
> > > -
> > > -pa_assert(c);
> > > -pa_assert(sink);
> > > -pa_assert(u);
> > > -pa_assert(u->on_rescue && u->restore_device);
> > > -
> > > -/* There's no point in doing anything if the core is shut down
> > > anyway */
> > > -if (c->state == PA_CORE_SHUTDOWN)
> > > -return PA_HOOK_OK;
> > > -
> > > -PA_IDXSET_FOREACH(si, sink->inputs, idx) {
> > > -char *name;
> > > -struct entry *e;
> > > -
> > > -if (!si->sink)
> > > -continue;
> > > -
> > > -/* Skip this sink input if it is connecting a filter sink to
> > > - * the master */
> > > -if (si->origin_sink)
> > > -continue;
> > > -
> > > -if (!(name = pa_proplist_get_stream_group(si->proplist,
> > > "sink-input", IDENTIFICATION_PROPERTY)))
> > > -continue;
> > > -
> > > -if ((e = entry_read(u, name))) {
> > > -
> > > -if (e->device_valid) {
> > > -pa_sink *d;
> > > -
> > > -if ((d = pa_namereg_get(c, e->device,
> > > PA_NAMEREG_SINK)) &&
> > > -d != sink &&
> > > -PA_SINK_IS_LINKED(d->state))
> > > -pa_sink_input_move_to(si, d, true);
> > > -}
> > > -
> > > -entry_free(e);
> > > -}
> > > -
> > > -pa_xfree(name);
> > > -}
> > > -
> > > -return PA_HOOK_OK;
> > > -}
> > > -
> > > static pa_hook_result_t source_unlink_hook_callback(pa_core *c,
> > > pa_source *source, struct userdata *u) {
> > > pa_source_output *so;
> > > uint32_t idx;
> > > @@ -2420,7 +2371,6 @@ int pa__init(pa_module*m) {
> > > if (restore_device && on_rescue) {
> > > /* A little bit earlier than module-intended-roles,
> > > module-rescue-streams, ... */
> > > -pa_module_hook_connect(m,
> > > >core->hooks[PA_CORE_HOOK_SINK_UNLINK], PA_HOOK_LATE,
> > > (pa_hook_cb_t) sink_unlink_hook_callback, u);
> > > pa_module_hook_connect(m,
> > > >core->hooks[PA_CORE_HOOK_SOURCE_UNLINK], PA_HOOK_LATE,
> > > (pa_hook_cb_t) source_unlink_hook_callback, u);
> > > }
> > > diff --git a/src/pulsecore/sink.c b/src/pulsecore/sink.c
> > > index cf43a78e8..d7973b7c9 100644
> > > --- a/src/pulsecore/sink.c
> > > +++ b/src/pulsecore/sink.c
> > > @@ -745,6 +745,9 @@ void pa_sink_unlink(pa_sink* s) {
> > > linked = PA_SINK_IS_LINKED(s->state);
> > > +if (linked)
> > > +pa_sink_move_streams_to_default_sink(s->core, s, false);
> > > +
> >
> > This is called too early. It might be the current default sink that we
> > are unlinking.
> >
> > > if (linked)
> > > pa_hook_fire(>core->hooks[PA_CORE_HOOK_SINK_UNLINK], s);
> I wonder if we should not drop this patch from the series. Otherwise I think
> it has to be re-worked a bit. If we keep it, part of the logic in
> module-rescue-stream
> needs to be copied to the core (and removed from module-rescue-stream).
> First, it is a good idea not to start moving sink-inputs around if the
> core is
> shutting down anyway and second, simply moving streams to the default
> sink may fail. As an example, if you set your default sink to a virtual sink
> and the master sink of the virtual sink goes away, you can't move the
> sink-input of the virtual sink to the default sink. module-rescue-stream
> has find_evacuation_sink() to determine where a sink input should be
> moved to. If the patch is re-worked, remember we also need a check for
> s->unlink_requested.
>
> Tanu, what would you
Re: [pulseaudio-discuss] [PATCH v12 01/13] bluetooth: Fix usage of MTU, buffer sizes and return values of encode/decode methods
On Fri, 2019-07-05 at 15:02 +0200, Pali Rohár wrote:
> /* Run from IO thread */
> static int a2dp_write_buffer(struct userdata *u, size_t nbytes) {
> int ret = 0;
>
> +if (PA_UNLIKELY(!nbytes)) {
> +u->write_index += (uint64_t) u->write_memchunk.length;
> +pa_memblock_unref(u->write_memchunk.memblock);
> +pa_memchunk_reset(>write_memchunk);
> +return 0;
> +}
Is this to handle a situation where the encoder accepts input but
doesn't produce any output (the algorithmic delay thing you mentioned
in the commit message)? This can't happen with SBC, right? I think
there should be a comment explaining when nbytes can be zero.
> @@ -578,9 +592,8 @@ static int a2dp_process_push(struct userdata *u) {
> pa_smoother_put(u->read_smoother, tstamp,
> pa_bytes_to_usec(u->read_index, >decoder_sample_spec));
> pa_smoother_resume(u->read_smoother, tstamp, true);
>
> -pa_memblock_release(memchunk.memblock);
> -
> -pa_source_post(u->source, );
> +if (PA_LIKELY(memchunk.length))
> +pa_source_post(u->source, );
I'm not sure about this. It sounds like it should be impossible that an
encoded frame results in no decoded data, so maybe an assertion would
make more sense? On the other hand, a simple check like this can't do
much harm, and if some codec indeed can return zero data, just skipping
pa_source_post() in that case seems correct.
--
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 v2 4/8] core: move sink-inputs conditionally when update default_sink
On Fri, 2019-07-12 at 20:52 +0200, Georg Chini wrote: > On 12.07.19 13:13, Tanu Kaskinen wrote: > > On Wed, 2019-07-10 at 22:03 +0200, Georg Chini wrote: > > > On 10.07.19 16:03, Tanu Kaskinen wrote: > > > > On Fri, 2019-07-05 at 10:57 +0200, Georg Chini wrote: > > > > > On 05.07.19 09:41, Tanu Kaskinen wrote: > > > > > > On Tue, 2019-07-02 at 09:08 +0200, Georg Chini wrote: > > > > > > > On 02.07.19 08:43, Tanu Kaskinen wrote: > > > > > > > > On Mon, 2019-07-01 at 08:03 +0200, Georg Chini wrote: > > > > > > > > > On 01.07.19 07:08, Tanu Kaskinen wrote: > > > > > > > > > When a new sink appears, pa_core_update_default_sink() is > > > > > > > > > called. Since > > > > > > > > > PulseAudio 11.1, bluetooth and USB sinks have higher priority > > > > > > > > > than the > > > > > > > > > internal sound card, so pa_core_update_default_sink() will > > > > > > > > > switch to > > > > > > > > > the BT speakers in your example. The main benefit of > > > > > > > > > module-switch-on- > > > > > > > > > connect was that it moved existing streams to the new sink, > > > > > > > > > but after > > > > > > > > > this patch set that's handled by the core. Therefore there's > > > > > > > > > much less > > > > > > > > > need for module-switch-on-connect. > > > > > > > > > > > > > > > > This is true, but only relevant if there is no configured default > > > > > > > sink. If the configured default sink is set, there will be no > > > > > > > switch > > > > > > > to a newly appearing sink because the configured default sink > > > > > > > is prioritized over all other sinks. In this case you still need > > > > > > > module-switch-on-connect. > > > > > > My estimation is that this is very rarely a problem. > > > > > Mh, my estimation is, that this will be the normal case. At some > > > > > point the user will set a default sink manually, and from that point > > > > > on, automatic switching will no longer work. The configured default > > > > > sink is never unset once it is set. > > > > Yes, sure, but I tried to explain why this is rarely a problem. (In > > > > another thread you described a valid use case where this becomes a > > > > problem, but I don't think that's a "normal case".) > > > > > > > > > > If you have manually selected an external sound card as the default > > > > > > sink and you then plug in another external sound card, then you may > > > > > > or > > > > > > may not want to automatically switch to the new sound card. If you > > > > > > fiddle a lot with two external sound cards and you always want to > > > > > > use > > > > > > the last one plugged in, then module-switch-on-connect is still > > > > > > useful, > > > > > > but in this case it doesn't really matter that your old default > > > > > > device > > > > > > choice is forgotten, because PulseAudio will anyway prefer the > > > > > > remaining external sound card. > > > > > This topic is not about forgetting the last sink, but about switching > > > > > to a new sink at all. Once you manually set the default sink, it will > > > > > never switch automatically without module-switch-on-connect, > > > > > because the default sink selection process prefers the configured > > > > > default sink over all other sinks. > > > > You're assuming that we always want to switch to a newly plugged in > > > > device. Let's say that you have just one USB device, no other external > > > > devices. If you for some reason set the internal sound card as the > > > > default device, I think it's a good thing that we don't automatically > > > > switch to that USB device when it's plugged in again. Therefore I think > > > > it's a good thing that we don't load module-switch-on-connect by > > > > default. > > > > > > > > If you in this situation plug in another external device, it would > > > > probabl
