Re: why does the int_value of the pa_json_object structure need to be declared as int64_t?

[Arun Raghavan]

On Tue, 9 Jul 2024, at 7:22 AM, 赵成义 wrote:
> Hi Arun,
>
>>Can I change "int64_t int_value;" to "int int_value;"?
>>In the ./src/pulse/format.c file, the function pa_json_object_get_int
>>is called multiple times, converting int64_t to int.
>
>>./src/pulse/format.c:
>>
>>int pa_format_info_get_prop_int(const pa_format_info *f, const char *key, int 
>>*v) {
>>  const char *str;
>>  pa_json_object *o;
>>
>>  pa_assert(f);
>>  pa_assert(key);
>>  pa_assert(v);
>>
>>  str = pa_proplist_gets(f->plist, key);
>>  if (!str)
>>  return -PA_ERR_NOENTITY;
>>
>>  o = pa_json_parse(str);
>>  if (!o) {
>>  pa_log_debug("Failed to parse format info property '%s'.", key);
>>  return -PA_ERR_INVALID;
>>  }
>>
>>  if (pa_json_object_get_type(o) != PA_JSON_TYPE_INT) {
>>  pa_log_debug("Format info property '%s' type is not int.", key);
>>  pa_json_object_free(o);
>>  return -PA_ERR_INVALID;
>>  }
>>
>>  *v = pa_json_object_get_int(o);
>
> I just want to avoid truncation or overflow errors caused by implicit 
> type conversion from int64_t to int here.
> If you think there is no problem with the conversion here, I will not 
> modify it.

Well, for reasons I don't recall, I made the pa_format_info work with int 
rather than int64_t. In practice, since we're mostly dealing with channel count 
and sampling rate, there will not be any truncation etc. on 32-bit platforms.

We can't change this as it's public API now, but we could add a int64 getter 
instead if there's a case for it.

-- Arun

Re: why does the int_value of the pa_json_object structure need to be declared as int64_t?

[Arun Raghavan]

On Mon, 8 Jul 2024, at 3:41 AM, 赵成义 wrote:
> Hi guys,
>
> Please help explain why the int_value of the pa_json_object structure 
> needs to be declared as int64_t.

I picked an int64_t because JSON does not specify a number precision, and I 
wanted to get the largest representation we could without having to actually 
resort to arbitrary precision integers.

> ./src/pulsecore/json.c:
>
> struct pa_json_object {
> pa_json_type type;
>
> union {
> int64_t int_value;
> double double_value;
> bool bool_value;
> char *string_value;
> pa_hashmap *object_values; /* name -> object */
> pa_idxset *array_values; /* objects */
> };
> };
>
> Can I change "int64_t int_value;" to "int int_value;"?
> In the ./src/pulse/format.c file, the function pa_json_object_get_int
> is called multiple times, converting int64_t to int.

Can you share a rationale for wanting to do this? On 64-bit systems, this 
conversion is a no-op, anyway, and on 32-bit systems I would expect the 
overhead to be minimal.

-- Arun

[ANNOUNCE] PulseAudio Volume Control 6.0

[Arun Raghavan]

Hi folks,
I'm pleased to announce the release of pavucontrol 6.0!

  tarball: 
http://freedesktop.org/software/pulseaudio/pavucontrol/pavucontrol-6.0.tar.xz
  sha256: 
http://freedesktop.org/software/pulseaudio/pavucontrol/pavucontrol-6.0.tar.xz.sha256sum

A quick summary of changes:

 * Migrate from Gtk 3 to 4.
 * Embed UI resources in executable.
 * Rename "Set as fallback" to "Default" for better legibility.
 * Support 144 Hz monitors with level bars.
 * App icons will fallback to generic rather than missing image, and this will 
be more common with Gtk 4.
 * Lots of translation updates.
 * Drop autotools build in favour of meson.
 * Make libcanberra dependency optional.

A big shoutout to Jean-Alexandre Anglès d'Auriac and Nicola Revelant for some 
recent heavy-lifting with the Gtk 4 port and other code modernisation efforts, 
and everyone else who's contributed to translations, bug reports, and code.

The build on Flathub will also be updated soon.

Cheers,
Arun

Re: I see no way to report a bug on "How to report a bug" wiki page

[Arun Raghavan]

On Mon, 11 Mar 2024, at 5:28 AM, Martin Guy wrote:
> Hi!
>
>    A pulseaudio bug has surfaced today - the server running out of file 
> descriptors when playing short music tracks continuously for over a week 
> - but on the "How to report a bug" wiki page
>
> https://www.freedesktop.org/wiki/Software/PulseAudio/BugReports
>
> I see nothing saying how to report a bug, and the gitlab project does 
> not seem to have an "Issues" section.
>
>
> Now, I know I am old and going blind, but am I really not seeing 
> something that should be obvious?

Could you please file a bug on the bug tracker so we can fix this?

:D j/k, I've added a link to this page as well now.

Cheers,
Arun

[ANNOUNCE] PulseAudio 17.0

[Arun Raghavan]

Hello!
After an unintentionally long gap from the last release candidate, I'm pleased 
to announce the release of PulseAudio 17.0.

tarball: 
https://www.freedesktop.org/software/pulseaudio/releases/pulseaudio-17.0.tar.xz
sha256sum: 053794d6671a3e397d849e478a80b82a63cb9d8ca296bd35b73317bb5ceb87b5

There are a whole bunch of bug fixes in here, plus a few improvements to ALSA 
UCM-based setups, Bluetooth support, echo cancellation, Windows/macOS fixes, 
and in a number of other areas. A full changelog can be found at 
https://www.freedesktop.org/wiki/Software/PulseAudio/Notes/17.0

It should be no surprise that development on PulseAudio has slowed down 
considerably. We expect significant new work to continue in PipeWire, 
WirePlumber, and related projects. There are some open MRs that we might 
shepherd through completion, notably some UCM improvements and _possibly_ 
support for compressed streams.

We're still around if any issues come up. Since libpulse is still the 
recommended API for most audio applications, it continues to be supported. 
There is some continuing work on Pavucontrol that we will also try to shepherd 
in. Our resources continue to be limited, so contributors' patience is greatly 
appreciated.

Despite the slower pace of development, there were 54 contributors in git to 
this release, and I want to extend our heartfelt thanks to them and all the 
folks on IRC, mailing lists, GitLab, and downstream in distributions for their 
time with testing, packaging, reporting, translations -- every form of 
contribution and support.

Have a great weekend!
Arun

Re: [pulseaudio-discuss] Has anyone configured for IP Phone Group Paging (aka Multicast RTP, using uLaw or aLaw or G.722 codec)?

[Arun Raghavan]

On Wed, 13 Sep 2023, at 12:31 PM, Pete Holzmann wrote:
> Turns out that almost every IP phone out there can be configured to 
> send and receive one-button speakerphone "paging" functionality.
>
> This standard capability uses multicast RTP, with specific IP and port 
> configured for each Page group. Most phones can monitor several groups.
>
> I am thinking that the exact same functionality would make a wonderful, 
> simple, whole-house intercom/paging system. "Time for dinner!" etc :-D
>
> Has anyone configured PulseAudio to send or receive these signals?
>
> I'd love to set up so:
> - in-ceiling speakers can play the "paging' message
> - various devices with a microphone can be used to initiate a "page"
> - etc...
>
> Am I missing something in thinking this ought to be quite doable with 
> this package?

It's doable, but not necessarily out of the box. We do have a couple of modules 
to send/receive RTP, and we can even detect streams on your network using SAP, 
but this is currently limited to L16 (16-bit PCM) and Opus: 
https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/blob/master/src/modules/rtp/sdp.c#L93

-- Arun

[pulseaudio-discuss] [ANNOUNCE] WebRTC AudioProcessing 1.3

[Arun Raghavan]

Hi all,
I've just rolled out version 1.3 of webrtc-audio-processing

tarball: 
https://freedesktop.org/software/pulseaudio/webrtc-audio-processing/webrtc-audio-processing-1.3.tar.xz
sha256: 2365e93e778d7b61b5d6e02d21c47d97222e9c7deff9e1d0838ad6ec2e86f1b9

This includes a single fix for the pkg-config file generated for the main 
library. Thanks to Nirbheek Chauhan for pinning this down!

Cheers,
Arun

[pulseaudio-discuss] [ANNOUNCE] WebRTC AudioProcessing 1.2

[Arun Raghavan]

Hi all,
I'd like to announce the release of v1.2 of the webrtc-audio-processing library.

tarball: 
https://freedesktop.org/software/pulseaudio/webrtc-audio-processing/webrtc-audio-processing-1.2.tar.xz
sha256: 38a3e1282f8265edf0fa40c0fcbdd5526680afd6ba827d1d193f3c5386646509

This is mainly a set of fixes to improve builds with abseil-cpp as a 
subproject, and to explicitly mark it as a dependency in pkg-config for 
downstream projects.

Happy Friday!
Arun

[pulseaudio-discuss] [ANNOUNCE] PulseAudio 16.99.1

[Arun Raghavan]

Hi all,
I've just uploaded the first release candidate for 17.0.

tarball: 
https://www.freedesktop.org/software/pulseaudio/releases/pulseaudio-16.99.1.tar.xz
sha256sum: dbb89a4c4a5f30f03b2c8c95de864ad53f7a40d4fdee29063f966cf66cfa800a

The release includes:

  * A bunch of bug fixes and minor features
  * Rework and improvement to UCM handling
  * Bluetooth FastStream codec support

A full changelog will be prepared for the final release.

As the UCM changes might affect various different hardware, testing and bug 
reports are much appreciated.

Cheers,
Arun

[pulseaudio-discuss] [ANNOUNCE] WebRTC AudioProcessing v1.1

[Arun Raghavan]

Hi folks,
I'd like to announce the release of v1.1 of the webrtc-audio-processing 
library. This release has a number of build fixes, and is backwards-compatible 
with v1.0.

tarball: 
https://freedesktop.org/software/pulseaudio/webrtc-audio-processing/webrtc-audio-processing-1.1.tar.xz
sha256: 945a7c5d6c604091815b34884e1fd95796942f1f906e3474f7cc882b7a8fd124

There are a number of build fixes for various platforms -- thanks to all our 
contributors, including Nirbheek Chauhan who's helped unravel some of the 
abseil-cpp messiness and widen our CI coverage significantly!

Packagers should note that we have dropped detection of CMake and manual 
installations of the abseil-cpp dependency -- pkg-config files are used to 
detect the system version, else the subproject is used for the build. This 
should simplify things for everyone, but feedback is welcome.

Cheers,
Arun

Re: [pulseaudio-discuss] echo-cancel module

[Arun Raghavan]

Hey Aaron,

On Fri, 19 Aug 2022, at 5:41 PM, Aaron Brice wrote:
> I'm having trouble getting the echo-cancel module working.  I'm running 
> pulseaudio 15.0 on an i.MX8QM arm embedded system, and trying to do 
> echo-cancel between the speakers and the mic to act as bluetooth 
> speakerphone.  For testing I am playing music through the echo-canceled 
> speaker sink and running parecord on the echo-canceled mic source.  I 
> can do either of those independently and it works.  However, when I 
> start parecord while playing through speakers, pulseaudio goes to 100% 
> CPU and journalctl shows the error "Resume failed, couldn't restore 
> original sample settings." streaming over and over.  Tried with 
> aec_method=null for test purposes and got the same result.

Can't be certain, but this seems like a driver problem.

You could try setting the default and alternate sample rates in 
/etc/pulse/daemon.conf to 48000 to see if that avoids this sample rate 
reconfiguration altogether.

Cheers,
Arun

Re: [pulseaudio-discuss] Stepping down as a maintainer

[Arun Raghavan]

Hi Tanu,

On Wed, 10 Aug 2022, at 8:24 AM, Tanu Kaskinen wrote:
> 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!

I am both excited about your new adventure, and gutted by the fact that you'll 
be leaving us.

Thank you for the tireless and often thankless work on PulseAudio, and 
hopefully we'll still see you around some.

Cheers!
Arun

Re: [pulseaudio-discuss] Audio only working after stopping PulseAudio and setting the UCM - kblda7219max on the ChromeOS Kernel, 5.10.70

[Arun Raghavan]

On Sun, 3 Apr 2022, at 10:27 PM, Navtej Bhatti wrote:
> On my `kblda7219max` Chromebook (baseboard: NAMI), internal audio works 
> properly when the following conditions are met:
> * Kernel 5.10.70 (ChromeOS fork) is used (the latest ChromeOS kernel 
> has some kind of topology-related kernel bug)
> * FW is copied from the ChromeOS rootfs to Linux
> * UCM is converted to UCM2
> * Only ALSA is used
>
> However, whenever I start PulseAudio (`pulseaudio -`), audio is 
> disabled, going to a dummy output.
>
> PulseAudio passes through probing for the UCM files but errors out in 
> this particular spot:
> ```
> I: [pulseaudio] (alsa-lib)pcm_hw.c: SNDRV_PCM_IOCTL_PREPARE failed (-22)
> I: [pulseaudio] alsa-util.c: snd_pcm_hw_params failed: Invalid argument
> D: [pulseaudio] alsa-util.c: Trying hw:kblda7219max,0 without 
> SND_PCM_NO_AUTO_FORMAT ...
> D: [pulseaudio] alsa-util.c: Managed to open hw:kblda7219max,0
> D: [pulseaudio] alsa-util.c: Maximum hw buffer size is 21845 ms
> I: [pulseaudio] (alsa-lib)pcm_hw.c: SNDRV_PCM_IOCTL_PREPARE failed (-22)
> I: [pulseaudio] (alsa-lib)pcm_hw.c: SNDRV_PCM_IOCTL_PREPARE failed (-22)
> I: [pulseaudio] (alsa-lib)pcm_hw.c: SNDRV_PCM_IOCTL_PREPARE failed (-22)
> I: [pulseaudio] (alsa-lib)pcm_hw.c: SNDRV_PCM_IOCTL_PREPARE failed (-22)
> ```
> which causes it to say:
> ```
> E: [pulseaudio] module-alsa-card.c: Failed to find a working profile.
> E: [pulseaudio] module.c: Failed to load module "module-alsa-card" 
> (argument: "device_id="0" name="platform-kbl_da7219_mx98357a" 
> card_name="alsa_card.platform-kbl_da7219_mx98357a" namereg_fail=false 
> tsched=yes fixed_latency_range=no ignore_dB=no deferred_volume=yes 
> use_ucm=yes avoid_resampling=no 
> card_properties="module-udev-detect.discovered=1""): initialization 
> failed.
> ```
>
> My `dmesg` gets filled with:
> ```
> Kbl Audio Port: ASoC: no backend DAIs enabled for Kbl Audio Port
> Kbl Audio Port: ASoC: dpcm_fe_dai_prepare() failed (-22)
> ```
>
> However, once I kill PulseAudio and run `alsaucm -c kblda7219max set 
> _verb HiFi set _enadev Speaker`, audio begins working again (but this 
> is in pure ALSA and PA apps are not compatible) and the `no backend 
> DAIs enabled for Kbl Audio Port` is no longer logged to `dmesg`.
>
> I think this is a UCM issue because the audio is working fine 
> kernel-level and with ALSA, but PulseAudio seems to mess something up 
> with the UCM and the UCM needs to be set again.
>
> I ended up removing the Front Mic, Rear Mic, and Mic, all of which were 
> connected to PCM3. PulseAudio worked, but I ended up frying (you could 
> smell something burning) my speaker, even at minimum volume :). I've 
> seen others document this. ALSA exhibits no such behavior (it worked 
> with apulse for months), but PulseAudio is able to burn your speaker. 
> It surprises me because PA operates only in the userspace.
>
> This whole setup is reproducible with my project, Breath, located here 
> .
> Attachments:
> * kblda7219max.conf.txt
> * HiFi.conf.txt
> * pulseaudio-log.txt
> * alsa-info (4).txt


Thanks for the detailed report Navtej. Could you file this on the bug tracker 
so we can potentially track this better?

  https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues

Cheers,
Arun

[pulseaudio-discuss] [ANNOUNCE] PulseAudio 16.0

[Arun Raghavan]

Hello!
I'm happy to announce that PulseAudio 16.0 is now out!

tarball: 
https://www.freedesktop.org/software/pulseaudio/releases/pulseaudio-16.0.tar.xz
sha256sum: b4ec6271910a1a86803f165056547f700dfabaf8d5c6c69736f706b5bb889f47

Quite a bit going on in this release as well,and full release notes at 
https://www.freedesktop.org/wiki/Software/PulseAudio/Notes/16.0/

Highlights include:

  * Time smoother and latency reporting fixes across the board, which should 
particularly make combine, tunnel and loopback significantly better
  * Tunnel modules should also be more robust with regards to reconnection
  * Bluetooth battery level reporting is now supported
  * RTP modules now support streaming Opus instead of PCM
  * pactl can now output JSON
  * Lots of other updates including translations, bug fixes, more hardware 
support and other improvements

Thanks to everyone for testing, reporting and helping get this out the door.

Have a great weekend!
Arun

Re: [pulseaudio-discuss] BLE Audio support in Pulse Audio

[Arun Raghavan]

On Mon, 23 May 2022, at 10:56 AM, pradeepkumar soman wrote:
> Hi All,
>
> I have some queries regarding the LE Audio support in Pulse Audio.
> 1. Do you know when the pulse audio will support the LE Audio profile?
> 2. Does it have the LC3 codec for supporting the LE Audio?
> 3. Will the A2DP profile be extended to provide support for the LE 
> audio profile or it will be a new profile?

Support will likely first need to be added in BlueZ (which I believe is an 
on-going effort). I expect that it will need to be a new implementation, though 
there might be some shared elements with A2DP.

Cheers,
Arun

[pulseaudio-discuss] [ANNOUNCE] PulseAudio 15.99.1

[Arun Raghavan]

Hello,
Happy Monday, everyone! We've just rolled out the first release candidate for 
PulseAudio 16.0.

tarball: 
https://www.freedesktop.org/software/pulseaudio/releases/pulseaudio-15.99.1.tar.xz
sha256sum: 63a9d6bc2db87ff53d6425125bba89ae7e4d1479aaed559c5286f00a9736ede6

There's quite a lot in this release, small summary below, which will be fleshed 
out in proper release notes form for the final release:

  * Bunch of rewinding fixes, particular around resampling
  * New time smoother implementation (should be quicker to sync, and less 
likely to seesaw)
  * Better sync and latency as a result in tunnel, combine, and loopback modules
  * Opus support for RTP streaming
  * Bluetooth device battery level reporting
  * JSON output from pactl
  * Additional hardware support
  * Other bug fixes, translation updates, and improvements

Packagers will want to be aware of a path change for modules (and a 
corresponding paprefs update is required). GStreamer support for RTP modules is 
now enabled by default, and will require Opus plugins for that feature to work.

As usual, please test and report any issues.

Cheers,
Arun

Re: [pulseaudio-discuss] ITP Bug#1003102

[Arun Raghavan]

Hi,

On Tue, 4 Jan 2022, at 3:51 AM, tangm...@uniontech.com wrote:
> I am currently doing push webrtc to the debian repository, which can 
[...]
> I noticed the webrtc-audio-processing project in
> https://salsa.debian.org/pulseaudio-team/webrtc-audio-processing
> is part  of webrtc.
>
> Now,  I want to confirm whether this module has the same function as 
> the audio-processing module in
> https://webrtc.googlesource.com/src
>
> If yes! If the webrtc-audio-processing module is integrated in the 
> libwebrtc library, is that will be OK?
>
> In other words,  do I need to bring the library prov ided through the 
> webrtc-audio-processing source package in the libwebrtc project?
>
> If yes, do I need to perform any necessary tests, and whether there are 
> existing reverse dependencies that need to be changed?

The webrc-audio-processing library is the AudioProcessing and AudioCoding 
module, copied over from libwebrtc, packaged with a more distribution-friendly 
build system.

I think your effort to package libwebrtc should be independent of this: these 
modules (which are internal to the library, in a sense) often break API, and we 
try to manage that in the distribution process so that downstream consumers of 
the library (PulseAudio, PipeWire, GStreamer) are able to have sensible 
dependency management.

Cheers,
Arun

Re: [pulseaudio-discuss] blocking call in pulse core mainloop context results in sink not getting data

[Arun Raghavan]

On Fri, 3 Sep 2021, at 6:24 AM, Ravikiran belur wrote:
> Thanks Arun.
> 
> I looked at the fix below for a similar mainloop blocking issue.
> https://lists.freedesktop.org/archives/pulseaudio-discuss/2013-May/017283.html
> 
> I wanted to make use of threaded mainloop for blocking operations like 
> below, so that the core mainloop is not blocked.
> Please suggest if this is possible.
> 
> /* Runs in PA core mainloop context */
> static void pa_core_api (pa_mainloop_api *api, void *userdata) {
> > /* call PA core APIs here*/
> }
> 
> /* Runs in local threaded mainloop context */
> static void blocking_func(pa_mainloop_api *api, void *userdata) {
> > /* make blocking operations here */
> > pa_mainloop_api_once(*core->mainloop*, pa_core_api, userdata); /* execute 
> > pa_core_api() in PA core mainloop context */ 
> }
> 
> /* Runs in PA core mainloop context */
> static void hook_callback() {
> > pa_threaded_mainloop_lock(u->threaded_mainloop);
> > pa_mainloop_api_once(*u->threaded_mainloop_api*, blocking_func, userdata); 
> > /* execute blocking_func() in threaded_mainloop context */ 
> > pa_threaded_mainloop_unlock(u->threaded_mainloop);
> }

You could do this, or just start up a thread and use a message queue using some 
of the utility functions we have (pa_thread_new() and pa_thread_mq).

-- Arun

[pulseaudio-discuss] [ANNOUNCE] PulseAudio 15.0

[Arun Raghavan]

Hi folks,
I'm happy to announce that PulseAudio 15.0 is out!

tarball: 
https://www.freedesktop.org/software/pulseaudio/releases/pulseaudio-15.0.tar.xz
sha256: a40b887a3ba98cc26976eb11bdb6613988f145b19024d1b6555c6a03c9cba1a0

This is a big release, and you likely want to see the full release notes at 
https://www.freedesktop.org/wiki/Software/PulseAudio/Notes/15.0/

Highlights

  * Lots of Bluetooth features (more A2DP codecs, native HFP support with mSBC 
for better audio quality, AVRCP Absolute Volume)
  * Card profiles can be made sticky, so (un)plugging does not reset state 
(helpful with HDMI replugging changing outputs, for examples)
  * New messaging API to allow easier extension of the core API
  * Virtual surround sink completely rewritten
  * Autotools dropped in favour of meson
  * Improved hardware support
  * ALSA path configuration can live in user home directory\
  * Translation updates
  * Bug fixes and a lot more

Package maintainers will want to check the relevant section of the release 
notes.

Special thanks go out to everyone who spent a lot of time testing, 
troubleshooting, and reporting issues from git builds and release candidates.

Finally, I'd also like to welcome Igor Kovalenko, Marijn Sujiten and Sanchayan 
Maity to the development team!

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

Re: [pulseaudio-discuss] Why does PA need to rewrite and rewind when I change the volume while playing audio?

[Arun Raghavan]

On Mon, 26 Jul 2021, at 11:18 PM, Chengyi Zhao wrote:
> Hi guys,
> 
> I found the following logic when I change the volume while playing 
> audio.I guess there is some audio expertise here, would you please tell 
> me the principle, thanks a lot!
> 
> In the file sink-input.c(./src/pulsecore/sink-input.c), why does pa need 
> to invoke the function pa_sink_input_request_rewind to rewrite and 
> rewind the data?

Because you might have a large buffer, and you want volume updates to be 
audible immediately. More details here:

https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/Developer/Rewinding/

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

Re: [pulseaudio-discuss] blocking call in pulse core mainloop context results in sink not getting data

[Arun Raghavan]

On Mon, 19 Jul 2021, at 3:23 PM, Ravikiran belur wrote:
> Hello,
> 
> A module in pulseaudio is using a blocking function in pa_hook_connect 
> callback.
> So the blocking function runs in PA core mainloop context for 40ms to 90ms.
> 
> This causes audio break/silence at the sink side, resulting in small 
> noise on the speaker during playback.
> 
> Can someone suggest a fix for this issue in module/pulseaudio?

This is not unexpected. Data from PulseAudio clients arrives in the main 
thread, so blocking for that long is not good.

The module should be performing the task that is taking so long asynchronously, 
or dispatching it to a separate thread.

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

[pulseaudio-discuss] [ANNOUNCE] PulseAudio 14.99.2

[Arun Raghavan]

Hi folks,
I've rolled out the next (and hopefully last) release candidate for the 15.0 
release.

tarball: 
https://www.freedesktop.org/software/pulseaudio/releases/pulseaudio-14.99.2.tar.xz
sha256: 4afb288046ca0dc7f7984dfb0f215c0afcdbcb915756a4396154e6936db72683

Updates since 14.99.1 include:

  * Addition of a sticky flag for profiles to not be changed by policy modules, 
set via the new messaging API
  * A set of Win32 updates (including the ability to run as a service)
  * Translation updates
  * Lots of meson-related build fixes
  * Updates for a few cards (some desktop on-board audio, Dell WD19 dock, 
Focusrite Saffire Pro I/O series, Sennheiser GSX 1200)
  * Bunch of other fixes

Please test and report any issues. Hopefully 15.0 is just around the corner!

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

[pulseaudio-discuss] IRC channel has moved

[Arun Raghavan]

Hi all,
Please note, the official IRC channel for PulseAudio has moved from Freenode to 
OFTC.

We also have a Matrix room bridged to IRC.

Details at 
https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Community/#ircandmatrix

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

[pulseaudio-discuss] [ANNOUNCE] PulseAudio 14.99.1

[Arun Raghavan]

Hi folks,
Hope you're all safe and well in these absurd times. I've just rolled out the 
first release candidate for 15.0.

tarball: 
https://www.freedesktop.org/software/pulseaudio/releases/pulseaudio-14.99.1.tar.xz
sha256: 9d4612665e8023bb71575fdf744c5530bc227979ec257bc5651b9c5d1b91c2ee

This is probably going to be the largest set of changes in a single release in 
a very long time. A non-comprehensive set of highlights include:

 * Support for more Bluetooth A2DP codecs, higher quality with SBC, and 
absolute volume
 * Native HFP implementation for better headset compatibility and call audio 
quality using the mSBC codec
 * New messaging API for clients to send messages to PulseAudio objects
 * Autotools build dropped in favour of meson
 * Rewrite of the virtual surround sink
 * Much improved win32 support
 * Improved support for a bunch of devices (docks, and USB headsets and 
interfaces)
 * A number of long-standing FreeBSD patches merged
 * Some new pactl getter commands for easier scripting
 * Many many translation, bug fixes, and other improvements

This is obviously a lot, so please test and report any problems in the usual 
places. We may have a late-breaking fix for HDMI devices being automatically 
selected after a suspend/resume cycle, but other than that, there should not be 
anything big before 15.0.

Early and incomplete release notes are here, and contributions to filling this 
in are welcome: https://www.freedesktop.org/wiki/Software/PulseAudio/Notes/15.0/

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

Re: [pulseaudio-discuss] Using PulseAudio's echo cancellation for a voice assistant

[Arun Raghavan]

Hi,

On Sat, 6 Mar 2021, at 1:09 AM, Giovanni Campagna wrote:
> Hello all,
> 
> I'm the developer of Almond (https://almond.stanford.edu), an open-
> source voice assistant, that is, an application that listens for
> commands from the user in voice (continuously until a specific word is
> heard) and then executes actions and replies.
> 
> Our assistant makes use of PulseAudio for audio frontend processing. I
> have enabled echo cancellation by setting "filter.want=echo-cancel" on
> both the record and playback streams, and the echo cancellation modules
> seem to load correctly, but it seems that echo cancellation is only
> performed between those two streams. Music or other audio that is not
> assistant speech will not be echo cancelled.
> 
> For the voice assistant use case, we would like to echo cancel against
> all outputs currently playing from the speaker where we're recording
> audio, so we have the clearest input from the user to convert to text.
> 
> Is it possible to implement that using PulseAudio? What would be the
> best way to do so?
> 
> Thanks in advance for the kind reply, and best,

For your sort of use-case, a static configuration to load module-echo-cancel 
and route the outputs you want to cancel to the echo-cancel sink should work 
better than using the filter.want property (which you'll need to set on _all_ 
streams that you intend to have participate in echo cancellation).

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

[pulseaudio-discuss] [ANNOUNCE] PulseAudio 14.1

[Arun Raghavan]

Hi folks,
I've just tagged and release the PulseAudio 14.1 release.

tarball: 
https://www.freedesktop.org/software/pulseaudio/releases/pulseaudio-14.1.tar.xz
sha256: b0bcca2a45e4fe1f73c7709dcf75a17dd5235688d5d150069e765dda4884b837

There were a few things in here that didn't make it to 14.0, plus a few fixes 
on top of that. There are still some bugs and MRs that are pending review and 
might make it to a 14.2, else will need to be tackled for 15.0 (depending on 
the bandwidth we get -- more help is always welcome!)

Changes in this release:

 * Support upto 8 mixer channels on ALSA devices
 * Handle ALSA jacks with the same name but different index values
 * Switch to plugged-in headset when mic availability is unknown
 * Fix a potential segfault in the Bluetooth oFono HFP backend
 * Fix a problem with module-ladspa-sink when avoid-resampling=true
 * Update to the NEWS file for 14.0 (and 14.1)
 * Fix database names containing canonical host for meson builds

For packagers who have switched to meson, the last item should be particularly 
relevant.

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

Re: [pulseaudio-discuss] Map sink-input to virtual microphone

[Arun Raghavan]

On Tue, 22 Dec 2020, at 2:04 AM, guest271314 wrote:
> This is the code that I cobbled together from your post, 
> https://askubuntu.com/questions/60837 and  
> https://aweirdimagination.net/2020/07/19/virtual-microphone-using-gstreamer-and-pulseaudio/
> 
> pactl load-module module-combine-sink \
> sink_name=Web_Speech_Sink slaves=$(pacmd list-sinks | grep -A1 "* 
> index" | grep -oP "<\K[^ >]+") \
> sink_properties=device.description="Web_Speech_Stream" \
> format=s16le \
> channels=1 \
> rate=22050
> 
> pactl move-sink-input $(pacmd list-sink-inputs|tac|perl 
> -E'undef$/;$_=<>;/speech-dispatcher-espeak-ng.*?index: (\d+)\n/s;say 
> $1') Web_Speech_Sink
> 
> pactl load-module module-remap-source \ master=Web_Speech_Sink.monitor 
> \ source_name=Web_Speech_Monitor \ 
> source_properties=device.description=Web_Speech_Output
> 
> Using this approach I am able to capture output from only 
> speech-dispatcher-espeak-ng module using
> 
> navigator.mediaDevices.getUserMedia({audio: true})
> .then(async stream => {
>   const [track] = stream.getAudioTracks();
>   const devices = await navigator.mediaDevices.enumerateDevices();
>   const device = devices.find(({label}) => label === 
> 'Web_Speech_Output');
>   track.stop();
>   console.log(devices, device);
>   return navigator.mediaDevices.getUserMedia({audio: {deviceId: {exact: 
> device.deviceId}}});
> })
> .then(stream => {
>   const recorder = new MediaRecorder(stream);
>   recorder.ondataavailable = e => 
> console.log(URL.createObjectURL(e.data));
>   const synth = speechSynthesis;
>   const u = new SpeechSynthesisUtterance('test, test, then test again');
>   u.onstart = e => {
> recorder.start();
> console.log(e);
>   }
>   u.onend = e => {
> recorder.stop();
> recorder.stream.getTracks().forEach(track => track.stop());
> console.log(e);
>   }
>   synth.speak(u);
> });
> 
> Can the pactl and pacmd code be reduced?

Almost certainly. The module-combine-sink can probably get a manual list of 
slave devices if you know the name of the physical sink, and it should also be 
possible to use `pactl move-sink-input ` instead to avoid the second 
bit of Perl munging.

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

Re: [pulseaudio-discuss] Delayed muting of studio speakers

[Arun Raghavan]

On Tue, 22 Dec 2020, at 1:45 PM, Chris Mayes wrote:
> Speaking of Spotify, I remembered that I'd selected "quiet" for the 
> volume level under Music Quality:
> 
> spotify_levels.png
> 
> I've switched it to "normal".  This ought to help with the signal 
> level, though I'd still like to find where this minimum signal 
> threshold is being enforced.  It may be in the speakers themselves, 
> especially since the left channel tends to mute before the right.  I've 
> written to the manufacturers, but I've yet to receive a response.
> 
> I'll see how well the "normal" volume level does at keeping the cutoff 
> at bay.  If I ever do hear from the manufacturer, I'll send an update.
[...]

This does indeed seem to be an issue with the speakers, given that output and 
the fact that the volume things fixes it. I found this random thread that 
suggests that you're not alone: 
https://www.gearslutz.com/board/low-end-theory/646410-krk-rp5-sound-breaks-up-cuts-out-occasionally.html

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

Re: [pulseaudio-discuss] Delayed muting of studio speakers

[Arun Raghavan]

On Sat, 19 Dec 2020, at 2:43 PM, Chris Mayes wrote:
> Hi, everybody!
> 
> It takes me back to have subscribed via Mailman to an email 
> distribution list.  I'm generally able to solve my issues via Googling, 
> but this one's proven tricky.

Welcome back to the past! :)

> I recently bought a pair of KRK Classic 5 
>  speakers to replace a pair of 
> M-Audio Studiophile AV 40 
>  speakers that had 
> developed a rapid popping noise in the internal amplifier.  The new 
> speakers sound fantastic, but they have an odd spontaneous muting 
> issue, at least as configured.
> 
> The issue is that the speakers seem to become muted (first one, then 
> the other, usually L->R) after some time of playing without any issues. 
>  My provisional solution is to crank the volume past 100%, which 
> un-mutes them (though at an unpleasantly loud volume).  This clears up 
> the issue, though it usually happens again a few minutes later once 
> I've brought the volume back to a reasonable level.
> 
> Based on my Googling, I tried modifying analog-output.conf.common to 
> "ignore" volume.  Here's the PCM block:
> 
> [Element PCM]
> switch = on
> volume = ignore
> volume-limit = 2.0
> override-map.1 = all
> override-map.2 = all-left,all-right
> 
> Sadly, this didn't seem to make any difference.  What else might I try?
> 
> I have a passing familiarity with audio concepts, and one difference 
> that I noted is that the new speakers have about half of the impedance 
> of the old pair (which never had this problem).  Do sound cards use 
> impedance to detect the presence of a device?  It's plugged into 
> line-out (lime green) on an Asus Xonar SE 
>  (the motherboard (Asus 
> PRIME Z390-A)  had 
> the same issue).
> 
> Also, the audio is fed to each speaker separately rather than being fed 
> to a single speaker and bridged to the left via speaker cable.  Maybe 
> that's a factor?
> 
> The brute-force thing would be to just mark the line-out port as 
> "always on" and to skip attempts to detect whether there's a device 
> connected.  Can PulseAudio do this?  More elegant solutions are also 
> warmly welcomed.

This is pretty odd. Could you run the pa-info script (hopefully it's packaged 
in your distribution) when the stream is playing fine vs. when it's not playing 
fine? The idea is to see if any mixer controls or any of the stream/sink 
volumes have actually changed when this happens, or if something else is going 
on lower down in the hardware.

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

Re: [pulseaudio-discuss] Map sink-input to virtual microphone

[Arun Raghavan]

On Mon, 21 Dec 2020, at 9:52 AM, guest271314 wrote:
> A virtual microphone can be created using module-remap-source 
> https://aweirdimagination.net/2020/07/19/virtual-microphone-using-gstreamer-and-pulseaudio/
> 
> pactl load-module module-remap-source \ master=virtmic.monitor 
> source_name=virtmic \ 
> source_properties=device.description=Virtual_Microphone
> 
> AFAICT a sink-input cannot be set as the source for the virtual microphone.
> 
> A sink-input can be recorded using parec or parecord --monitor-stream option
> 
> parecord -v -r --monitor-stream=26 --file-format=wav output.wav
>  
> How to set a sink-input as source for the virtual microphone so that 
> the output of the sink-input is still played back to speakers or 
> headphones and simultaneously is the source of the virtual microphone?

You could use module-combine-sink to play that sink input to a null-sink and 
the real sink, and then use the null-sink's monitor as your source.

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

Re: [pulseaudio-discuss] [ANNOUNCE] WebRTC AudioProcessing v1.0

[Arun Raghavan]

On Fri, 27 Nov 2020, at 2:48 PM, Arun Raghavan wrote:
> Hi folks,
> I'd like to announce the release of v1.0 of the webrtc-audio-processing 
> library. Please note that the 1.0 doesn't really mean much outside of 
> the update to the versioning system described below.
> 
> tarball: 
> http://freedesktop.org/software/pulseaudio/webrtc-audio-processing/webrtc-audio-processing-1.0.tar.gz
> sha256: f53d627d952094f2a1c4484a7730ff8b2e5a3805975d4aa7a60a3dc370890f01

Unfortunately, I messed up the tarball generation. This has been fixed now:

sha256: 441a30d2717b2eb4145c6eb96c2d5a270fe0b4bc71aebf76716750c47be1936f

The tag in git is unchanged, this was just a bad tarball due to me not having 
made a release after the move to meson.

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

[pulseaudio-discuss] [ANNOUNCE] WebRTC AudioProcessing v1.0

[Arun Raghavan]

Hi folks,
I'd like to announce the release of v1.0 of the webrtc-audio-processing 
library. Please note that the 1.0 doesn't really mean much outside of the 
update to the versioning system described below.

tarball: 
http://freedesktop.org/software/pulseaudio/webrtc-audio-processing/webrtc-audio-processing-1.0.tar.gz
sha256: f53d627d952094f2a1c4484a7730ff8b2e5a3805975d4aa7a60a3dc370890f01

This is an API breaking release (as a reminder, the AudioProcessing module does 
not provide a stable public API, so we expose whatever API exists in the 
upstream project).

In order to make package management easier with these inevitable breakages, the 
package is now suffixed with a version (currently it is 
webrtc-audio-processing-1). When the next API break happens, we will bump the 
major version, allowing incompatible versions to coexist. This also means that 
the previous version can also coexist with this one. Non-breaking changes will 
see a minor version update only.

Changes:
  * The code base is now updated to correspond to the version shipping with the 
Chromium 88.0.4290.1 tag
  * There are a very large number changes to the underlying AEC implementation 
since the last update was a while ago. Most visibly the use of the AEC3 
canceller by default, the deletion of the beamformer code
  * The autotools build system is replaced by meson
  * The pkg-config name is changed as described above

I have only really been able to test this release on x86_64, and compile-test 
on aarch64. Additional testing and reports on 32-bit ARM, MIPS, and non-Linux 
OSes would be greatly appreciated. Please file issues on Gitlab if you find any.

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

Re: [pulseaudio-discuss] [ANNOUNCE] PulseAudio 14.0

[Arun Raghavan]

On Thu, 26 Nov 2020, at 3:56 PM, Felipe Sateler wrote:
[...]
> >   * New GStreamer-based RTP backend (off by default)
> 
> The release notes are confusing:
> 
> > The old RTP implementation is still available as a compile time option 
> > (--disable-gstreamer with Autotools or -Dgstreamer=disabled with Meson), 
> > but the GStreamer implementation is used by default. The GStreamer 
> > implementation should be considered experimental for this release
> 
> 1. This contradicts the above quote.
> 2. If it's experimental, why is it enabled by default? 

Whoops, thanks for pointing this out. I've updated the release notes to 
correctly reflect that the GStreamer backend is disabled by default.

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

[pulseaudio-discuss] [ANNOUNCE] PulseAudio 14.0

[Arun Raghavan]

Hi folks,
Looks like we finally managed to get this one out, just shy of a year past the 
due date (admittedly there are some mitigating circumstances this year!)

tarball: 
https://www.freedesktop.org/software/pulseaudio/releases/pulseaudio-14.0.tar.xz
sha256: a834775d9382b055504e5ee7625dc50768daac29329531deb6597bf05e06c261

There's a _lot_ that went into this release, so the highlights below really 
aren't complete, and you want to see the full release notes at 
https://www.freedesktop.org/wiki/Software/PulseAudio/Notes/14.0/

  * Rerouting streams when the default sink/source changes is now in the core
  * Much improved UCM support, which is now used on newer Intel SOF (Sound Open 
Firmware) based devices
  * Ports now expose their type and "availability group" for UIs to discover 
which ports are mapped to the the same physical jack (for "what did you plug 
in" UIs)
  * New GStreamer-based RTP backend (off by default)

A lot of people have helped with reporting bugs, submitting translations,  
testing the point releases, and patiently helping pin down issues, in addition 
to all the code contributions. Our heartfelt thanks go out to all of you. 
Special mentions: Hui Wang for a number of routing features, Jaroslav Kysela 
for much of the UCM heavy-lifting, and Igor Kovalenko for helping us take the 
14.0 release past the finish line with triage, debugging and fixes.

The release notes also has a section for package maintainers this time, so 
please take a look and shout at us if you see anything amiss.

Cheers!
Arun
___
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 ?

[Arun Raghavan]

On Wed, 4 Nov 2020, at 10:59 PM, 01iv...@labomedia.org wrote:
[...]
> A BIG THANK YOU !
> It perfectly works !
> 
> I'm going to try in few days with many more sound cards but is there a 
> known limit to the number of sink which can be create this way ?
> Is 40 something completely crazy to think about ?

There isn't a limit on sinks per-se, just whatever resources your computer has 
for resampling/mixing/etc.

-- Arun
___
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 ?

[Arun Raghavan]

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
___
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 ?

[Arun Raghavan]

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
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

[pulseaudio-discuss] [ANNOUNCE] PulseAudio 13.99.3

[Arun Raghavan]

Hi everyone,
We found a few more papercuts in 13.99.2 than we'd hoped for, so here's one 
more RC to make sure things are stable now.

tarball: 
https://www.freedesktop.org/software/pulseaudio/releases/pulseaudio-13.99.3.tar.xz
sha256: 60fdb5f619c85dfe3e018ad0ee1d8f6fe9041885c2e8b6ded724c855880276c8

Since 13.99.2, we've fixed some issues that came up with mixer configuration, 
availability groups being populated correctly, some jitter while streaming with 
the experimental GStreamer RTP backend, a couple of use-after-free crashes, and 
some default sink/source routing corner cases. Thanks to everyone who 
participated in testing, debugging and ironing these out!

Please do test, and assuming things are quiet, I'll roll out 14.0 next week. As 
before, the plan is to roll out some more SoF-related fixes in 14.1.

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

Re: [pulseaudio-discuss] pulse resolution change from jack

[Arun Raghavan]

On Sun, 20 Sep 2020, at 6:26 PM, matt wrote:
> Hello, my name is Matt I do the librequest podcast, not lately however. 
> But anywho, Leo from MintCast in episode 344 has outlined a fix for 
> pulse and jack interacting in regard to resolution changes in audio 
> sampling and how they affect output processing when different 
> resolutions are introduced to the pulse system. I didn't know if this 
> could be implemented in a way that could fix the issue of the 
> resolution changing for jack users during use of usb sound cards. I 
> have experienced this issue since 2012 when I first used the Scarlett 
> 2i2 and also with the solo that I currently use. He uses a different 
> usb audio interface, not sure which one. But his solution is as follows.

There's some discussion about what seems to be the same issue at:

  https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/980

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

[pulseaudio-discuss] [ANNOUNCE] PulseAudio 13.99.2

[Arun Raghavan]

Hey everyone,
It's been a long wait, but I've finally pushed out the PulseAudio 13.99.2 (aka 
14.0 RC2) release tarballs.

tarball: 
https://www.freedesktop.org/software/pulseaudio/releases/pulseaudio-13.99.2.tar.xz
sha256: 38a3c4f6c9450c952ce69ec4d6a2829a123b189ce8bfeeb9924a632f7149334e

The plan is to merge some minor pending stuff and roll out 14.0 soon. There are 
some more fixes for newer ALSA SoF-based devices using using UCM, but those 
might take a bit longer and will ship in 14.1.

Full release notes are work-in-progress, but this one has a new availability 
group mechanism to help UIs identify ports associated with the same jacks, a 
bunch of UCM-related changes, plus fixes for RAOP, the GStreamer RTP backend, 
Creative Audigy cards.

Distributions shipping GNOME should consider the 
"stream-restore-clear-old-devices" option in autotools/meson (see 
https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/298).

Please package, test and help us get a stable 14.0 out the door soon!

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

[pulseaudio-discuss] shut down pulseaudio-commits?

[Arun Raghavan]

Hi folks,
Since we've moved to gitlab, where you can subscribe to project and/or 
repository notifications (for commits, issues and MRs), the pulseaudio-commits 
list is now redundant.

Does anyone have objections to stopping updates going out to this list, and 
maybe disabling email to it altogether?

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

[pulseaudio-discuss] PulseAudio on the web

[Arun Raghavan]

Hi folks,
Thought some of you might find this usage of PulseAudio interesting:

  https://cloud.google.com/solutions/gpu-accelerated-streaming-using-webrtc

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

Re: [pulseaudio-discuss] Correct User Setup on an Embedded Device

[Arun Raghavan]

On Fri, 24 Jul 2020, at 8:29 AM, jtharkey wrote:
> We're trying to get away from running PA in system mode on an embedded 
> device because of performance. We have the problem that our app must 
> run as root, however. Right now I'm doing this:
> 
> We have two users on the system, root and the app's
> The app's user logs in and runs PA
> The app's user sudos the app to run as root
> 
> This works great except it breaks bluetooth audio support. Is this the 
> correct way to go about this or do we need to change our approach?

Are you working with very low latencies, or such? And have you been able to 
measure a performance improvement in user-mode?

Because outside of low latency use-cases, I'd expect the memcpy() overhead on 
most modern systems is small enough to not be a deciding factor.

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

Re: [pulseaudio-discuss] Weird jack detection on ASRock B450M Pro4

[Arun Raghavan]

On Fri, 10 Jul 2020, at 11:31 AM, Arun Raghavan wrote:
> Hi folks,
> I ran into some weird behaviour on this motherboard. First, alsa-info 
> is here: 
> http://alsa-project.org/db/?f=f48105f391d848b34b3779f27369130ca024f417
> 
> The weird behaviour is that the HDA card is picked up fine, but jack 
> detection is broken on boot. However, this gets "fixed" after you run 
> alsa-info. The before/after codec info is at:

Quick note, the same behviour is seen on unplug/replug on that port as well 
(i.e. unplug is detected, but replug is not until alsa-info is run again).

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

[pulseaudio-discuss] Weird jack detection on ASRock B450M Pro4

[Arun Raghavan]

Hi folks,
I ran into some weird behaviour on this motherboard. First, alsa-info is here: 
http://alsa-project.org/db/?f=f48105f391d848b34b3779f27369130ca024f417

The weird behaviour is that the HDA card is picked up fine, but jack detection 
is broken on boot. However, this gets "fixed" after you run alsa-info. The 
before/after codec info is at:

https://arunraghavan.net/temp/alsa-codecs-before.txt
https://arunraghavan.net/temp/alsa-codecs-after.txt

The key delta is:


@@ -133,24 +133,24 @@
 Node 0x02 [Audio Output] wcaps 0x41d: Stereo Amp-Out
   Control: name="Front Playback Volume", index=0, device=0
 ControlAmp: chs=3, dir=Out, idx=0, ofs=0
   Device: name="ALC892 Analog", type="Audio", device=0
   Amp-Out caps: ofs=0x40, nsteps=0x40, stepsize=0x03, mute=0
-  Amp-Out vals:  [0x34 0x34]
-  Converter: stream=0, channel=0
+  Amp-Out vals:  [0x29 0x29]
+  Converter: stream=5, channel=0
   PCM:
 rates [0x560]: 44100 48000 96000 192000
 bits [0xe]: 16 20 24
 formats [0x1]: PCM
   Power states:  D0 D1 D2 D3 EPSS
   Power: setting=D0, actual=D0
 Node 0x03 [Audio Output] wcaps 0x41d: Stereo Amp-Out
   Control: name="Surround Playback Volume", index=0, device=0
 ControlAmp: chs=3, dir=Out, idx=0, ofs=0
   Amp-Out caps: ofs=0x40, nsteps=0x40, stepsize=0x03, mute=0
-  Amp-Out vals:  [0x34 0x34]
-  Converter: stream=0, channel=0
+  Amp-Out vals:  [0x29 0x29]
+  Converter: stream=5, channel=0
   PCM:
 rates [0x560]: 44100 48000 96000 192000
 bits [0xe]: 16 20 24
 formats [0x1]: PCM
   Power states:  D0 D1 D2 D3 EPSS
@@ -159,12 +159,12 @@
   Control: name="Center Playback Volume", index=0, device=0
 ControlAmp: chs=1, dir=Out, idx=0, ofs=0
   Control: name="LFE Playback Volume", index=0, device=0
 ControlAmp: chs=2, dir=Out, idx=0, ofs=0
   Amp-Out caps: ofs=0x40, nsteps=0x40, stepsize=0x03, mute=0
-  Amp-Out vals:  [0x34 0x34]
-  Converter: stream=0, channel=0
+  Amp-Out vals:  [0x29 0x29]
+  Converter: stream=5, channel=0
   PCM:
 rates [0x560]: 44100 48000 96000 192000
 bits [0xe]: 16 20 24
 formats [0x1]: PCM
   Power states:  D0 D1 D2 D3 EPSS
@@ -172,11 +172,11 @@
 Node 0x05 [Audio Output] wcaps 0x41d: Stereo Amp-Out
   Control: name="Headphone Playback Volume", index=0, device=0
 ControlAmp: chs=3, dir=Out, idx=0, ofs=0
   Amp-Out caps: ofs=0x40, nsteps=0x40, stepsize=0x03, mute=0
   Amp-Out vals:  [0x00 0x00]
-  Converter: stream=0, channel=0
+  Converter: stream=5, channel=0
   PCM:
 rates [0x560]: 44100 48000 96000 192000
 bits [0xe]: 16 20 24
 formats [0x1]: PCM
   Power states:  D0 D1 D2 D3 EPSS


Any thoughts on what's changing that, and how this should be fixed?

Cheers,
Arun
___
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

[Arun Raghavan]

+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:
> > >>
> > >>
> > > The silent stream is enabled with a Kconfig option, as well as a 
> > > kernel
> > > parameter should there be a need to override the build time default.
> > 
> >  I'm not sure whether the module option is the best interface.
> >  An alternative is a mixer element that controls dynamically.  Then
> >  it'll be per card unlike the module option.
> > >>>
> > >>> +1, kcontrol seems the appropriate way to control this.
> > >>
> > >> It was my suggestion to use Kconfig+kernel parameter for
> > >> simplicity/overrides.
> > >>
> > >> The kcontrol is a nice idea, but in practice we typically only have
> > >> one card dealing with HDMI.
> > >
> > > Not really.  There are systems with two HDMI outputs from both
> > > integrated and discrete GPUs.  Most modern systems are only with
> > > hybrid graphics, though.
> > 
> > Ok, maybe I am mistaken, in most of the HDMI issues we've seen only
> > one HDMI source.
> > 
> > But it's a good point that this is only supposed to be used for Intel
> > whether it's a kernel parameter or a kcontrol shouldn't this be
> > dependent on a PCI ID being detected and a SKYLAKE flag being set?
> > it's my understanding that this applies from Skylake to TigerLake, not
> > before.
> 
> I guess we can check it from the codec ID?  Change the probe function
> for Skylake+ codecs to patch_i915_skl_hdmi and co, and set the flag
> there.
> 
> > >> 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.

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

Re: [pulseaudio-discuss] 回复: How to fix pulseaudio crash when playing music

[Arun Raghavan]

Hi Chengyi,

On Tue, 9 Jun 2020, at 10:13 AM, Chengyi Zhao wrote:
>  Hi Georg,
> 
>  Thanks for your reply!
> 
>  Hi all, 
> 
>  I try to apply the following patch to fix this issue, please help 
> review, thanks!
> 
> Date: Tue Jun 9 22:09:36 2020 +0800
> 
>  srb: ignore srb when reading/writing srb generated an exception
> 
>  When the function do_read() returns -1, the program continues
>  reading the same srb, maybe it will occur the crash.

Are you able to reproduce this deterministically? Do you know why the read 
fails?

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

Re: [pulseaudio-discuss] module-sine: dump samples to file

[Arun Raghavan]

On Tue, 16 Jun 2020, at 11:38 AM, massimiliano cialdi wrote:
> how can I dump module-sine generated samples to a file?

What are you trying to do?

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

Re: [pulseaudio-discuss] Purpose of ports that represent multiple UCM devices?

[Arun Raghavan]

On Sun, 14 Jun 2020, at 9:18 AM, Jaroslav Kysela wrote:
> Dne 10. 06. 20 v 11:20 Arun Raghavan napsal(a):
> > On Wed, 10 Jun 2020, at 5:15 AM, Tanu Kaskinen wrote:
> >> 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.
> > 
> > UCM has the notion of being able to have multiple concurrently active 
> > devices in a verb. For example, for a phone with headphones plugged in, 
> > when a ringtone/alarm needs to be played, you might want to enable the 
> > handset and headphone device.
> > 
> > This is done with the SupportedDevices/ConflictDevices options in UCM.
> > 
> > While the use case is still relevant, I'm not sure if there are better ways 
> > to do this. I'll let Jaroslav chime in on that.
> 
> At first, there's a bug in the PA code which skips the combination of the 
> devices without both supported/conflicting lists:
> 
> diff --git a/src/modules/alsa/alsa-ucm.c b/src/modules/alsa/alsa-ucm.c
> index 1dfb0e08b..9f7a84c52 100644
> --- a/src/modules/alsa/alsa-ucm.c
> +++ b/src/modules/alsa/alsa-ucm.c
> @@ -1182,9 +1182,6 @@ static int ucm_check_conformance(
>   return 0;
>   }
>   }
> -} else { /* not support any other devices */
> -pa_log_debug("Not support any other devices");
> -return 0;
>   }
> 
>   pa_log_debug("Device added to combination, number %d", dev_num + 1);
> 
> 
> ... but the specification is really straight about this case (use-case.h):
> 
> "Note that at most one of the supported/conflicting devs lists has
> any entries, and when neither is present, all devices are supported."
> 
> So my above patch will follow the specification.
> 
> The simultaneous use of UCM devices is allowed. But I agree that the 
> usability 
> for the desktop is a bit questionable. Users mostly expect to route the audio 
> to one device.

The multiple devices are a lot of noise, so I'm okay not being spec-compliant 
here. If this becomes problematic, we can make it a config flag on the module.

Better yet, we could change the UCM spec in this regard if other clients also 
agree.

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

Re: [pulseaudio-discuss] Purpose of ports that represent multiple UCM devices?

[Arun Raghavan]

On Wed, 10 Jun 2020, at 5:15 AM, Tanu Kaskinen wrote:
> 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.

UCM has the notion of being able to have multiple concurrently active devices 
in a verb. For example, for a phone with headphones plugged in, when a 
ringtone/alarm needs to be played, you might want to enable the handset and 
headphone device.

This is done with the SupportedDevices/ConflictDevices options in UCM.

While the use case is still relevant, I'm not sure if there are better ways to 
do this. I'll let Jaroslav chime in on that.

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

Re: [pulseaudio-discuss] Webrtc AEC Raspberry Pi weird effects.

[Arun Raghavan]

Hi Stuart,

On Wed, 13 May 2020, at 10:33 AM, Stuart Naylor wrote:
>  
> I will post the recordings.
> 
>  EC
> https://drive.google.com/file/d/13WCq9Bs-cW-cJsGFwU9s6DZ2UNLPXyMU/view?usp=sharing
> 
> 
> No-EC
> 
> https://drive.google.com/file/d/1HH5klDS_Y5Lcmsuc2EWsBO517V4dwLV0/view?usp=sharing

So I take it this is with webrtc?

What you're 

>  If I run speexdsp AEC with exact same setup but via alsa with 
> pulseaudio removed then the results are quite good.
>  The speaker is only 12” from the mic and 12” from me and quite loud as 
> wondering what upstairs thinks.
>  But anyway the results are pretty good.
> 
>  EC
> 
> https://drive.google.com/file/d/1ohO0YaO3CEwrXWwcj8qDbUpWuQo5sv2T/view?usp=sharing
> 
> 
> No-EC
> 
> https://drive.google.com/file/d/12qNv6O9o-ttFoWE9tytqXdbAKCkPT6NW/view?usp=sharing

Ah, that is quite good!

> Journalctl is giving the usual but this is a single usb soundcard with 
> single clock for capture/playback.
> 
>  May 13 14:14:30 raspberrypi pulseaudio[608]: E: [alsa-source-USB 
> Audio] module-echo-cancel.c: Doing resync
> 
>  May 13 14:14:30 raspberrypi pulseaudio[608]: E: [alsa-source-USB 
> Audio] module-echo-cancel.c: Playback too far ahead (37856), drop
> 
>  May 13 14:14:49 raspberrypi pulseaudio[608]: E: [alsa-source-USB 
> Audio] module-echo-cancel.c: Doing resync
> 
>  May 13 14:14:49 raspberrypi pulseaudio[608]: E: [alsa-source-USB 
> Audio] module-echo-cancel.c: Playback too far ahead (131103), dro
> 
>  May 13 14:14:49 raspberrypi pulseaudio[608]: E: [alsa-source-USB 
> Audio] module-echo-cancel.c: Doing resync
> 
>  May 13 14:14:49 raspberrypi pulseaudio[608]: E: [alsa-source-USB 
> Audio] module-echo-cancel.c: Playback too far ahead (75977), drop
> 
>  May 13 14:14:50 raspberrypi pulseaudio[608]: E: [alsa-source-USB 
> Audio] module-echo-cancel.c: Playback too far ahead (62480), drop
> 
>  May 13 14:14:51 raspberrypi pulseaudio[608]: E: [alsa-source-USB 
> Audio] module-echo-cancel.c: Playback too far ahead (13404), drop
> 
>  May 13 14:14:52 raspberrypi pulseaudio[608]: E: [alsa-source-USB 
> Audio] module-echo-cancel.c: Playback too far ahead (10231), drop
> 
>  May 13 14:14:53 raspberrypi pulseaudio[608]: E: [alsa-source-USB 
> Audio] module-echo-cancel.c: Playback too far ahead (9131), drop
> 
>  May 13 14:14:54 raspberrypi pulseaudio[608]: E: [alsa-source-USB 
> Audio] module-echo-cancel.c: Playback too far ahead (9136), drop
> 
>  May 13 14:14:55 raspberrypi pulseaudio[608]: E: [alsa-source-USB 
> Audio] module-echo-cancel.c: Playback too far ahead (9651), drop
> 
>  May 13 14:14:56 raspberrypi pulseaudio[608]: E: [alsa-source-USB 
> Audio] module-echo-cancel.c: Playback too far ahead (9915), drop
> 
>  May 13 14:14:57 raspberrypi pulseaudio[608]: E: [alsa-source-USB 
> Audio] module-echo-cancel.c: Playback too far ahead (9814), drop
> 
>  May 13 14:14:58 raspberrypi pulseaudio[608]: E: [alsa-source-USB 
> Audio] module-echo-cancel.c: Playback too far ahead (10011), drop
> 
>  May 13 14:15:00 raspberrypi pulseaudio[608]: E: [alsa-source-USB 
> Audio] module-echo-cancel.c: Playback after capture (-580), drop
> 
>  May 13 14:15:03 raspberrypi pulseaudio[608]: E: [alsa-source-USB 
> Audio] module-echo-cancel.c: Playback after capture (-158), drop
> 
>  May 13 14:15:20 raspberrypi pulseaudio[608]: E: [alsa-sink-USB Audio] 
> alsa-sink.c: ALSA woke us up to write new data to the device
> 
>  May 13 14:15:20 raspberrypi pulseaudio[608]: E: [alsa-sink-USB Audio] 
> alsa-sink.c: Most likely this is a bug in the ALSA driver 's
> 
>  May 13 14:15:20 raspberrypi pulseaudio[608]: E: [alsa-sink-USB Audio] 
> alsa-sink.c: We were woken up with POLLOUT set -- however a

The source dropped messages are from us trying to do drift compensation and 
matching the samples we believe correspond to each other given we know what the 
playback and capture latencies are.

Now if your device driver does not report the ALSA pointer correctly, this can 
throw the latency reports, and thus the AEC off. In your ALSA-only test, you 
are likely not exercising the ALSA API in the same way as PulseAudio does (for 
power saving etc.).

Do you see the same problem if you load the ALSA modules with tsched=off?

> I am sure there is something not quite write with the 
> webrtc_audio_processing when it comes to arm Linux maybe even just the 
> Pi which here is a Pi4.
>  Anyone any idea why the first EC with pulseaudio is so bad whilst even 
> the supposedly weaker speexdsp aec actually makes quite a good job with 
> exactly same hardware and setup?

I think one thing to do is minimise the dropped source/sink buffers, to get 
some steady performance.

Another way to experiment is to load module-echo-cancel with save_aec=true. 
This will dump the playback, capture, and cancelled data to /tmp.

You can then run echo-cancel-test (you'll need to have a PA build handy), which 
allows you to rerun on the same input with different AEC engines/parameters. 
However, all this only makes sense if you 

Re: [pulseaudio-discuss] module-echo-cancel vad

[Arun Raghavan]

Hey Stuart,

On Wed, 15 Apr 2020, at 7:34 AM, Stuart Naylor wrote:
>  
> Been trying to work out what voice_detection does I know its VAD but in 
> terms of pulseaudio struggling to work out any effect or process?
>  Is it me? 
> 
>  If you look at  
> https://github.com/freedesktop/pulseaudio-webrtc-audio-processing/tree/master/webrtc/common_audio/vad
>  Then also much is the same.
> 
>  Webrtc has vad and it would be great if that could either change 
> stream params to phone or cork/duck or something.
>  I have been playing with AEC on a PI that isn’t great to be honest as 
> often the result is an attenuated ‘vocody’ stream but actually if the 
> vad could trigger cork/duck then it would be great to use.
> 
>  So on the off chance it isn’t me, would there be any interest in 
> linking webrtc vad to pulseaudio functionality, unfortunately speex vad 
> seems only part of the codec rather than speexdsp but vad to cork/duck 
> functionality parameters would be great IMHO.
> 
>  Just thought I would float that as presuming it would be a minimal 
> addition with little effect on existing.

We don't really do anything with the VAD -- we just enable the module in the 
hope that the AEC algorithm itself will use the information.

You might not be able to use the duck/cork modules directly, but you could 
potentially implement something like it in module-echo-cancel (the code for 
those modules is actually factored out into a stream-interaction.c file, so 
there might be some easy-to-use bits there).

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

[pulseaudio-discuss] PulseAudio 13.99.1

[Arun Raghavan]

Hi folks,
I've finally managed to steal some time to roll out the first release 
candidate for 14.0. This will almost certainly not cause a
supervolcano, or make seagulls your preferred method for garbage
disposal.

tarball: 
https://www.freedesktop.org/software/pulseaudio/releases/pulseaudio-13.99.1.tar.xz
sha256: e6a111cc078e6039bf657a3fd1f73dc804c8ee362ca03a0732dc5c38c13e0a0c

Changes include a bunch of behavioural changes around default sink 
selection for a better user experience, ALSA UCM support, disabling
flat volumes by default, stream rescue moving to core, GStreamer-based
RTP support, and qpaeq moving to Python 3.

Happy testing!
Arun

[1] https://xkcd.com/2261/
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Streaming Audio from Android to remote PulseAudio server

[Arun Raghavan]

Hi,

On Fri, 6 Dec 2019, at 1:08 PM, Shakthi Prashanth wrote:
> Hi All,
> 
> I want to stream Audio from Android to remote PulseAudio server. How to 
> do it ?
> IMO, I need to build Pulse audio client library for Android (libpulse 
> ?), which will be used by Android ? Please advise what will be the 
> right/optimal way to do it ?

I don't know how current this is, but maybe it's a good starting point: 
https://github.com/pelya/pulseaudio-android

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

Re: [pulseaudio-discuss] Proposal for a new API and usage of Bluetooth HSP and HFP profiles on Linux

[Arun Raghavan]

+Wim and George from PipeWire

On Tue, 3 Dec 2019, at 12:15 AM, Pali Rohár wrote:
> On Monday 02 December 2019 19:01:11 Tanu Kaskinen wrote:
> > 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?
> 
> Yes, I can maintain this new daemon.
> 
> > It's not clear to me how this would affect the PulseAudio <-> oFono
> > interaction, if at all.
> 
> Only one application can register to bluez and "own" bluez socket for
> communication with bluetooth headset. Currently it can be either
> 

Re: [pulseaudio-discuss] License problem: LDAC codec & pulseaudio

[Arun Raghavan]

On Fri, 19 Apr 2019, at 3:34 PM, Tanu Kaskinen wrote:
> On Fri, 2019-04-19 at 00:17 +0200, Pali Rohár wrote:
> > On Saturday 23 February 2019 17:59:57 Tanu Kaskinen wrote:
> > > On Sat, 2019-02-23 at 16:06 +0100, Pali Rohár wrote:
> > > > Hello,
> > > > 
> > > > I would like to discuss about licence problems with usage of LDAC
> > > > encoder libldac in pulseaudio. LDAC is a codec used by some Sony
> > > > bluetooth headsets and it would be nice to have support for it after my
> > > > patch series for Modular API for A2DP codecs is merged.
> > > > 
> > > > There is only one released LDAC encoder. It is libldac which can be
> > > > found at: https://android.googlesource.com/platform/external/libldac/
> > > > It is licensed under Apache License Version 2.0.
> > > > 
> > > > If I understood correctly pulseaudio is licensed under LGPL v2.1 or
> > > > later with some exceptions when some optional GPL dependences are
> > > > enabled then server part is licensed under GPL v2 or later. So it can be
> > > > distributed under GPL v3, right? Please correct me if I'm wrong.
> > > > 
> > > > According to FSF https://www.gnu.org/licenses/license-list.html#apache2
> > > > Apache License Version 2.0 is compatible with GPL v3, but is
> > > > incompatible with GPL v2.
> > > > 
> > > > So, would it be feasible to write LDAC specific code for pulseaudio
> > > > under GPL v3 license (in separate files) and make compile time option to
> > > > enable/disable GPL v3 LDAC support? When enabled it would mean that
> > > > compiled binary of puleaudio server and server modules are forced to be
> > > > distributed under GPL v3 and thanks to compatibility with Apache License
> > > > Version 2.0, it would be possible to use libdac library. When disabled
> > > > then it would be like before (without LDAC and with license like
> > > > before). Am I correct?
> > > 
> > > Yes, I believe you're correct, and at least I am fine with adding LDAC
> > > support via libldac.
> > 
> > I asked people in SUSE and I got answer that it should be ok if there is
> > no GPLv2-only code. So has pulseaudio some GPLv2-only code or is all code
> > compatible with GPLv3 (i.e. GPLv2-or-later)?
> 
> PulseAudio doesn't have any GPL code, but it has optional GPL
> dependencies, all of which seem to be either GPLv2-or-later or GPLv3-
> or-later (gdbm is the one that is nowadays licensed under GPLv3). The
> LICENSE file could be more clear on these details...
> 
> You suggested writing LDAC specific code under GPLv3, but since
> LGPLv2.1-or-later is convertible to GPLv3, I think the LDAC code should
> be under LGPLv2.1-or-later like the rest of the code base.

Just saw this, sorry. This is why I intend to move all our codec-specific bits 
of BlueZ to use GStreamer and have as little codec-specific code in PulseAudio 
as possible. These choices should be at a system-integration level (i.e. 
selecting what plugins are available).

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

Re: [pulseaudio-discuss] Connect to non system-wide pulse server inside root privilege program (Asynchronous API)

[Arun Raghavan]

On Tue, 5 Nov 2019, at 3:50 PM, Andrey wrote:
> Hi all!
> 
> Pf: Issue with pa_context_connect() call inside root privilege program.
> 
> I have Xubuntu 19.10. On default pulseaudio server (ver 13.0) started on 
> user logon with "--demonize=no" parameter. I need reroute digital sound 
> from /dev/dsp  to pulse. For this i install osspd  package (current ver 
> 1.3.2-11). I have successfully used this package previously on Ubuntu 
> 16.04/18.04-3 with no any tuning. Osspd daemon get source trough CUSE 
> and required root privileges. I.e. osspd call pulse as root. I copy 
> user's cookie file to /root/.config/pulse/cookie. But osspd can't 
> connect to pulse server again. My distribution belongs to group 2 and i 
> no put users to the "audio" group (but i test opposed: nothing happens :) ).
> 
> I debug osspd's slave processes (ossp-padsp) and detect what function 
> pa_context_connect() return code 'connection refused'. I tried to run 
> ossp-padsp as user - it connected to server successful. Then i call 
> pa_context_connect() with name of server 
> "unix:/run/user/1000/pulse/native" (instead NULL) the connection is 
> established! And as ordinary user and as root! It works for me now.
> 
> BUT... I assume that somewhere something with settings of access rights 
> to the pulse server I missed... What and where? How correctly should I 
> connect to the non system-wide pulse server as root?
> 
> Is this behavior of the connection process a normal(documented?) or bug? 
> Can i (is it right) use this feature to select the specific user's pulse 
> server to connect?

Not sure what the issue you have is, but there is one big hammer to sidestep 
this problem -- you can provide auth_anonymous=1 to module-native-protocol-unix 
in default.pa, and any local client can then connect.

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

Re: [pulseaudio-discuss] [PATCH v13 03/10] bluetooth: Parse remote timestamp from A2DP RTP packets when available

[Arun Raghavan]

On Sun, 10 Nov 2019, at 2:24 PM, Pali Rohár wrote:
> On Saturday 09 November 2019 13:08:34 Georg Chini wrote:
> > On 06.10.19 19:58, Pali Rohár wrote:
> > > Some A2DP codecs (e.g. SBC or aptX-HD) use RTP packets. For sources use
> > > timestamps from RTP packets to calculate read index and therefore remote
> > > timestamp for synchronization.
> > > ---
> > >   src/modules/bluetooth/a2dp-codec-api.h   |  4 ++--
> > >   src/modules/bluetooth/a2dp-codec-sbc.c   |  3 ++-
> > >   src/modules/bluetooth/module-bluez5-device.c | 14 +++---
> > >   3 files changed, 15 insertions(+), 6 deletions(-)
> > > 
> > > diff --git a/src/modules/bluetooth/a2dp-codec-api.h 
> > > b/src/modules/bluetooth/a2dp-codec-api.h
> > > index a3123f4ca..1fd8e81d0 100644
> > > --- a/src/modules/bluetooth/a2dp-codec-api.h
> > > +++ b/src/modules/bluetooth/a2dp-codec-api.h
> > > @@ -91,8 +91,8 @@ typedef struct pa_a2dp_codec {
> > >   size_t (*encode_buffer)(void *codec_info, uint32_t timestamp, const 
> > > uint8_t *input_buffer, size_t input_size, uint8_t *output_buffer, size_t 
> > > output_size, size_t *processed);
> > >   /* Decode input_buffer of input_size to output_buffer of 
> > > output_size,
> > >* returns size of filled ouput_buffer and set processed to size of
> > > - * processed input_buffer */
> > > -size_t (*decode_buffer)(void *codec_info, const uint8_t 
> > > *input_buffer, size_t input_size, uint8_t *output_buffer, size_t 
> > > output_size, size_t *processed);
> > > + * processed input_buffer and set timestamp */
> > > +size_t (*decode_buffer)(void *codec_info, uint32_t *timestamp, const 
> > > uint8_t *input_buffer, size_t input_size, uint8_t *output_buffer, size_t 
> > > output_size, size_t *processed);
> > >   } pa_a2dp_codec;
> > >   #endif
> > > diff --git a/src/modules/bluetooth/a2dp-codec-sbc.c 
> > > b/src/modules/bluetooth/a2dp-codec-sbc.c
> > > index 89c647fbe..733c1a9ab 100644
> > > --- a/src/modules/bluetooth/a2dp-codec-sbc.c
> > > +++ b/src/modules/bluetooth/a2dp-codec-sbc.c
> > > @@ -597,7 +597,7 @@ static size_t encode_buffer(void *codec_info, 
> > > uint32_t timestamp, const uint8_t
> > >   return d - output_buffer;
> > >   }
> > > -static size_t decode_buffer(void *codec_info, const uint8_t 
> > > *input_buffer, size_t input_size, uint8_t *output_buffer, size_t 
> > > output_size, size_t *processed) {
> > > +static size_t decode_buffer(void *codec_info, uint32_t *timestamp, const 
> > > uint8_t *input_buffer, size_t input_size, uint8_t *output_buffer, size_t 
> > > output_size, size_t *processed) {
> > >   struct sbc_info *sbc_info = (struct sbc_info *) codec_info;
> > >   struct rtp_header *header;
> > > @@ -657,6 +657,7 @@ static size_t decode_buffer(void *codec_info, const 
> > > uint8_t *input_buffer, size_
> > >   frame_count--;
> > >   }
> > > +*timestamp = ntohl(header->timestamp);
> > >   *processed = p - input_buffer;
> > >   return d - output_buffer;
> > >   }
> > > diff --git a/src/modules/bluetooth/module-bluez5-device.c 
> > > b/src/modules/bluetooth/module-bluez5-device.c
> > > index 9da5d1ac3..fb77afaad 100644
> > > --- a/src/modules/bluetooth/module-bluez5-device.c
> > > +++ b/src/modules/bluetooth/module-bluez5-device.c
> > > @@ -556,6 +556,7 @@ static int a2dp_process_push(struct userdata *u) {
> > >   struct msghdr m;
> > >   bool found_tstamp = false;
> > >   pa_usec_t tstamp;
> > > +uint32_t timestamp;
> > >   uint8_t *ptr;
> > >   ssize_t l;
> > >   size_t processed;
> > > @@ -591,8 +592,6 @@ static int a2dp_process_push(struct userdata *u) {
> > >   pa_assert((size_t) l <= u->decoder_buffer_size);
> > > -/* TODO: get timestamp from rtp */
> > > -
> > >   for (cm = CMSG_FIRSTHDR(); cm; cm = CMSG_NXTHDR(, cm)) {
> > >   if (cm->cmsg_level == SOL_SOCKET && cm->cmsg_type == 
> > > SO_TIMESTAMP) {
> > >   struct timeval *tv = (struct timeval*) CMSG_DATA(cm);
> > > @@ -613,7 +612,8 @@ static int a2dp_process_push(struct userdata *u) {
> > >   ptr = pa_memblock_acquire(memchunk.memblock);
> > >   memchunk.length = pa_memblock_get_length(memchunk.memblock);
> > > -memchunk.length = u->a2dp_codec->decode_buffer(u->decoder_info, 
> > > u->decoder_buffer, l, ptr, memchunk.length, );
> > > +timestamp = 0; /* Decoder does not have to fill RTP timestamp */
> > > +memchunk.length = u->a2dp_codec->decode_buffer(u->decoder_info, 
> > > , u->decoder_buffer, l, ptr, memchunk.length, );
> > >   pa_memblock_release(memchunk.memblock);
> > > @@ -623,6 +623,14 @@ static int a2dp_process_push(struct userdata *u) {
> > >   break;
> > >   }
> > > +/* Some codecs may provide RTP timestamp, so use it to update 
> > > read_index for calculation of remote tstamp */
> > > +if (timestamp) {
> > > +/* RTP timestamp is only 32bit 

Re: [pulseaudio-discuss] Problem: non-interactive pulseaudio ( headless )

[Arun Raghavan]

On Tue, 3 Sep 2019, at 12:13 AM, Brian Bulkowski wrote:
> Thanks for the response, if you don't believe this is a good use, I 
> won't bother further. GStreamer, then.

If you have something working with PulseAudio, it might make sense to keep it 
and maybe change incrementally rather than going back to the drawing board.

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

Re: [pulseaudio-discuss] Problem: non-interactive pulseaudio ( headless )

[Arun Raghavan]

Hey Brian,

On Mon, 2 Sep 2019, at 11:45 AM, Brian Bulkowski wrote:
> Hey Arun,
> 
> Thanks for responding.
> 
> > I usually point folks to the sync-playback.c test that we have a starting 
> > point, but this is certainly less than ideal.
> 
> "less than ideal" is quite the politeness. Let's see
> 
> 1) it doesn't cover files, nor does it cover files of different types ( 
> mp3 vs wav )
> 
> Files are very good because they always work locally, which is critical 
> in art installations where you are being paid to deliver an experience, 
> regardless of whether there is connectivity. Unlike streams. Streams are 
> useless.

Not that there are good ways to discover this, but imo PulseAudio is not the 
best fit for either of these cases. PulseAudio makes sense when you have PCM 
data that you want to get out of some output, and you want fairly low-level 
access to the audio API.

IMO it is better to use a higher-level API such as GStreamer where you can 
easily say "play this file/URI/..." and have things "just work". You a volume 
API there, as well as a way to drop lower and select devices etc.

That said, you'd still likely want it to go through PulseAudio, and there'd 
still be the same hoops to jump through to get the seamless headless setup.

(As an aside, the stream abstraction is what it is because that is how the 
audio hardware works -- you open it, get it started, and provide a stream of 
audio, then stop it and close it when you're done. The low level APIs do not 
have a notion of playing a file, just a continuous stream of audio.)

> 2) it doesn't cover changing sounds in response to an "interrupt", that 
> is, pressing a button on an art installation.

That's not really in an audio API's purview.

> 3) it doesn't cover multiple "layers", that is, different sound 
> experiences being added or subtracted by buttons.

Same as above, I don't think the audio API is the right place to document how 
to do this.

I don't have a good answer for what the right place to document this is, but 
it's basically "how to write an event-driven application that plays sound". The 
first part can be done in a number of ways (roll your own, GLib, Qt), and the 
second also has a number of choices as I described above.

> Pulse audio is great all all of this, just that the example code is, to 
> put it your polite fashion, less than ideal, or where I come from, an 
> embarrassment.

Sure. The project is driven more or less entirely by volunteer bandwdith, and 
we each pick the points of focus that best match our interests and the time we 
have after dealing with personal and professional commitments, etc.

Documentation unfortunately loses priority in this, as the to-do list is (or at 
least feels) more or less infinite. Your criticism is valid, and welcome. 
Patches would also be most welcome (but not providing them does not invalidate 
your criticism).

> The code I've written allows external REST requests, and allows the 
> player to make REST requests to find current state. REST being the 
> current lingua franca of the internet. And allows both volume changes 
> and source file changes. Hopefully committed literally tomorrow, putting 
> it through some extra tests. Will post with a permissive license.

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

Re: [pulseaudio-discuss] Problem: non-interactive pulseaudio ( headless )

[Arun Raghavan]

Hey Brian,
Sorry about the lack of response on this. Just saw this now, and I'm glad you 
got things running.

On Sun, 1 Sep 2019, at 5:18 AM, Brian Bulkowski wrote:
> Here's what I learned:
> 
> 1. PulseAudio paired with a Rapsberry Pi is an almost unbeatable choice 
> for art installations. The ability to attach many speakers over USB 
> audio, the fact that there are no fans whatsoever, the fact that is can 
> run any manner of high level software to control sound, that you can add 
> flash drives which are as large as you like, the fact that you can 
> determine which USB port is which, the fact that you can easily add 
> buttons and interaction ( since it's a PI ), the ability to control 
> volume at any level ( speaker, sound, etc ), the easy code to use any 
> manner of sound file it's great.
> 
> 2. The async interface is not well covered in many guides. The examples 
> are misleading. As an experienced programmer with 30+ years of async c, 
> I got caught by this, because the examples worked ( but don't if you 
> start and stop a lot ). I will be posting my project and showing how to 
> really play sounds and start and stop them.

I usually point folks to the sync-playback.c test that we have a starting 
point, but this is certainly less than ideal.

> 3. If you are going to run an unattended service, you need to set 
> pulseaudio to be a systemd service, and you need to set up your 
> application as a systemd service.
> 
> In order to do this, you would typically use the 'cookie' file, which is 
> a binary file of undocumented type ( possibly just the contents of the 
> file ) which more than one process need access to. My attempts to get 
> this working with PulseAudio 12.0 failed, with environment variables 
> ignored, a service auto-creating a file with privs hard to read, but it 
> turns out there's a simple workaround. The documentation unhelpfully 
> says "maybe this is a good idea for something like an unattended 
> headless application but you're probably not running one of those".

The documentation is catered to users across the spectrum of use-cases and 
expertise, but I'm happy to incorporate suggestions for better phrasing for 
this.

> The way out, when you get desperate of using cookie files ( and do try 
> them first ), is  to modify the /etc/pulse/system.pa and find the 
> load-module line for module-native-protool-unix . Add the 
> auth-anonymous=1 as below
> 
> load-module module-native-protocol-unix auth-anonymous=1
> 
> This disables checks, and means that anyone who has access to the 
> raspberry pi can take over the audio, even if they have a non-pulse or 
> non-audio user. An installation like this should be air-gapped anyway.
> 
> 4. I can't say "thanks for the excellent community" as I spent lots of 
> hours on this project, but the underlying code has been sound, so thanks 
> for writing and contributing it.
> 
> 5. When the code is fixed, I'll post a link for others to use.

Thanks for your patience and for writing down your findings for others.

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

[pulseaudio-discuss] PulseAudio 12.99.3

[Arun Raghavan]

Hello again,
Another week, another release candidate. :) This should be the last one unless 
something goes horribly wrong.

tarball: 
https://www.freedesktop.org/software/pulseaudio/releases/pulseaudio-12.99.3.tar.xz
sha256: 5d93bccbfedc2510bd1766a0e66a5f0c3da8064d3464248c8c9b979f36a6612b

Changes include some translation updates, a new script (pa-info) to collect 
information for debugging information, a RAOP fix for network disconnects, no 
longer loading module-device-manager for newer KDE Plasma versions, no longer 
using X11 root window properties except on SSH connections, and an large number 
of meson build fixes.

Please test away and report regressions. If things are quiet, we'll roll a 
final release in a few days.

Happy weekend to all!
Arun
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

[pulseaudio-discuss] PulseAudio 12.99.2

[Arun Raghavan]

Hi folks,
I've pushed out the tarballs for 12.99.2.

tarball: 
https://www.freedesktop.org/software/pulseaudio/releases/pulseaudio-12.99.2.tar.xz
sha256: 8efa1e56501c85442b1f499ef5be14347799b6519e8bbcb43e417fca58abf02b

Changes since 12.99.1 are relatively minor. A few Bluetooth-related fixes from 
Pali, last minute support for a new SteelSeries Arctis 7 model (more of these 
will come post 13.0), some translation updates, fix for SSE svolume code with 
GCC 9, and a whole bunch of fixes to make the meson build to make it 
autotools-equivalent

Shout out to Jan Alexander Steffens (heftig) for doing a _lot_ of early testing 
to catch so many things that I missed.

Bug reports go to Gitlab as usual 
(https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues)

13.0 release blockers are tracked at 
https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/174

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

Re: [pulseaudio-discuss] PulseAudio 12.99.1

[Arun Raghavan]

On Tue, 9 Jul 2019, at 8:55 AM, Arun Raghavan wrote:
> Hi folks,
> I've just pushed out the tarballs for the long overdue PulseAudio 
> 12.99.1 (for the new folks here, that's 13.0 RC1).

Please note that if you're on x86, using GCC 9.1 and _not_ using Orc, there is 
a regression with software volumes. This should be fixed by: 
https://gitlab.freedesktop.org/pulseaudio/pulseaudio/merge_requests/124

I'll try to spin up an RC2 in the next couple of days, along with anything else 
that turns up.

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

[pulseaudio-discuss] PulseAudio 12.99.1

[Arun Raghavan]

Hi folks,
I've just pushed out the tarballs for the long overdue PulseAudio 12.99.1 (for 
the new folks here, that's 13.0 RC1).

tarball: 
https://www.freedesktop.org/software/pulseaudio/releases/pulseaudio-12.99.1.tar.xz
sha256: 1001206668f099cce03985b5ae39707aefaae04e9078a273c7c505d51153be31

New features include: a meson build system (coexisting with autotools for now), 
support for BlueZ 4 is dropped, constified various bits in headers, fixes for 
suspend-handling on newer Intel chipsets, and a lot of fixes across the board. 
A full changelog will be available with the final release.

Testing of the meson build would be appreciated. We will probably prefer to 
move to that as the single default build system within a release or two.

Embarrassingly, I lost my GPG private key while moving laptops, so the tag is 
signed with a new key (which should still have a similar chain of trust to the 
previous one).

Bug reports go to Gitlab as usual 
(https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues)

13.0 release blockers are tracked at 
https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/174.

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

Re: [pulseaudio-discuss] Pavucontrol on Flathub

[Arun Raghavan]

On Tue, 2 Jul 2019, at 10:28 AM, Tanu Kaskinen wrote:
[...]
> Once we've set up the procedures for maintaining the flatpak ourselves,
> is there any reason to have a separate repository for it? Shouldn't the
> flatpak stuff go to the main pavucontrol repo? Not that I have anything
> against having push rights to the current github repo for now. (By "the
> procedures" I mean documenting how to update the flatpak build files
> and how to test them, and following that documentation when doing
> releases.)

I think it might be worth having it on flathub to be able to use all the 
existing CI infrastructure over there.

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

Re: [pulseaudio-discuss] Pavucontrol on Flathub

[Arun Raghavan]

On Mon, 1 Jul 2019, at 11:26 AM, Tanu Kaskinen wrote:
> On Sat, 2019-06-29 at 10:37 +0530, Arun Raghavan wrote:
> > Hi folks,
> > Just a heads-up -- Will Thompson has nice enough to create a flatpak
> > for pavucontrol. It's on flathub, so you can see it at:
> > 
> >   https://flathub.org/apps/details/org.pulseaudio.pavucontrol
> > 
> > Instructions on installing are also on that page.
> > 
> > For those who are unfamiliar with it, flatpak provides a way to run
> > applications in a sandbox, against a standard distribution-neutral
> > runtime. Flathub is a repository for a number of such applications.
> > 
> > The code for the flatpak of pavucontrol is at:
> > 
> >   https://github.com/flathub/org.pulseaudio.pavucontrol
> 
> That's great!
> 
> What are your views on what we should or shouldn't do with this in the
> future? Ideally we'd maintain it upstream, because as a user I'd prefer
> to trust the upstream rather than some third party when installing
> flatpaks (and if the upstream maintains the flatpak, it will probably
> be always up to date). It would just mean some extra work for us when
> doing releases.

Yup, I think we should maintain this (Will had asked that we do that while 
writing it, and and I'd signed up for that but more hands are definitely 
welcome). I'll ask Nick Richards to give write permissions to you and George 
(or ideally the PulseAudio organisation).

> At least the appdata.xml file looks like something that we should
> maintain ourselves.

Agreed, but it depends on dropping intltool apparently.

> We should probably advertise this on the pavucontrol home page.

Agreed!

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

[pulseaudio-discuss] pulseaudio master is frozen

[Arun Raghavan]

Hi folks,
As we were discussing, 13.0 is a bit overdue, so we're freezing master now. 
Release tracker issue is at:

  https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/174

Just as a refresher, this means we will not be landing any new features to 
master without an explicit exception, and only critical bug fixes should land 
outside of those changes.

We used to keep a temporary 'next' branch for the times where the freeze cycle 
went longer and we didn't want to hold reviewed patches back. This may not be 
necessary any more with the Gitlab merge request system

We have discussed an exception for Pali's initial A2DP fixes, Russell's info 
script, and the fixes for the pending bug on the tracker relating to detecting 
when we are running in a VM.

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

[pulseaudio-discuss] Pavucontrol on Flathub

[Arun Raghavan]

Hi folks,
Just a heads-up -- Will Thompson has nice enough to create a flatpak for 
pavucontrol. It's on flathub, so you can see it at:

  https://flathub.org/apps/details/org.pulseaudio.pavucontrol

Instructions on installing are also on that page.

For those who are unfamiliar with it, flatpak provides a way to run 
applications in a sandbox, against a standard distribution-neutral runtime. 
Flathub is a repository for a number of such applications.

The code for the flatpak of pavucontrol is at:

  https://github.com/flathub/org.pulseaudio.pavucontrol

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

Re: [pulseaudio-discuss] plan/timeline for a release

[Arun Raghavan]

On Sat, 8 Jun 2019, at 12:09 PM, Tanu Kaskinen wrote:
> On Thu, 2019-06-06 at 18:39 +0200, Arun Raghavan wrote:
[...]
> > I suggest we timebox this -- what we are able to confidently review
> > and get in over the next 2 weeks makes to go into master before the
> > freeze, the rest we can push to next as it's ready, for 14.0 and
> > ideally we'll go back to your shorter release cycle for it so it's
> > not a very long wait.
> 
> I'm fine with delaying the freeze by two weeks. Freeze on 2019-06-20
> then (that's two weeks after your message)?

I did some bad calculations. I meant to freeze at the end of the month (so 
2019-06-30). We have ~4 days left, and I'm happy to help push along anything 
that needs to be done urgently.

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

Re: [pulseaudio-discuss] plan/timeline for a release

[Arun Raghavan]

On Wed, 5 Jun 2019, at 7:29 PM, Pali Rohár wrote:
> On Wednesday 05 June 2019 09:57:01 Georg Chini wrote:
> > On 04.06.19 19:42, Tanu Kaskinen wrote:
> > > On Fri, 2019-05-31 at 16:59 +0300, Kai Vehmanen wrote:
> > > > Hi all,
> > > > 
> > > > I've been testing pulse with the new Intel SOF [1] audio drivers (that 
> > > > are
> > > > going to 5.2 kernel).
> > > > 
> > > > In my tests, e.g. system suspend/stress tests work much better on latest
> > > > master of pulseaudio, compared to test with latest released Pulseaudio.
> > > > 
> > > > At least this patch in PA master has a big improvement:
> > > > "alsa: Improve resume logic after alsa suspend"
> > > > https://gitlab.freedesktop.org/pulseaudio/pulseaudio/commit/f7b3537bbf9a6916ee3fd72a82025519b4c346f5
> > > > 
> > > > With that introduction, any plans for an official Pulseaudio release 
> > > > this
> > > > year? It seems there are many patches in master (like the above) and 
> > > > time
> > > > has passed since 12.2.
> > > > 
> > > > [1] https://thesofproject.github.io/
> > > There are no concrete plans at the moment, but we certainly should make
> > > a release this year (preferably two). According to the usual process we
> > > should have started preparing the release last October, but somehow
> > > that didn't happen... The reason I didn't push for a release last fall
> > > was that there's a certain feature that I secretly wanted to get in
> > > first, and that's still not done. There hasn't been much pressure from
> > > other people either.
> > > 
> > > I think we could freeze master now. I don't want to block the release
> > > waiting for any features, such as the A2DP codec stuff. Arun, Georg,
> > > what are your thoughts?
> > > 
> > I'd like to have the messaging patches in the upcoming release.
> > It should not be too much work to review them and I think I fixed
> > all issues you found during your last review (except one that you
> > can probably fix easily when pushing the patches).
> > Otherwise I would be fine with freezing master and preparing
> > a new release. Do we have any blocker bugs?
> 
> I would like to see reviewed and merged first 5 patches in my bluetooth
> series. Those are just fixes of current code, not new A2DP codecs.

I hoping we could get some of those codec changes in before the release and 
held of suggesting a freeze earlier, but it since slipped my mind and I think 
we should in fact make a release soon.

I suggest we timebox this -- what we are able to confidently review and get in 
over the next 2 weeks makes to go into master before the freeze, the rest we 
can push to next as it's ready, for 14.0 and ideally we'll go back to your 
shorter release cycle for it so it's not a very long wait.

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

Re: [pulseaudio-discuss] [PATCH v5 0/7] New API for Bluetooth A2DP codecs

[Arun Raghavan]

On Sat, 26 Jan 2019, at 2:15 PM, Pali Rohár wrote:
> On Saturday 26 January 2019 07:39:54 Arun Raghavan wrote:
> > On Fri, 25 Jan 2019, at 3:19 PM, Tanu Kaskinen wrote:
> > > On Sat, 2019-01-19 at 18:11 +0100, Pali Rohár wrote:
> > > > This is 5th version of my patch series for modular A2DP codec API and
> > > > aptX support. The only change for v5 is support for switching codecs.
> > > > 
> > > > This patch series provides new modular API for Bluetooth A2DP codecs,
> > > > clean up module-bluez5-device and bluez5-util to be codec independent
> > > > and convert SBC codec into this new API for A2DP codecs. Also it adds
> > > > support for aptX, aptX HD and FastStream A2DP codecs.
> > > > 
> > > > New codec API is designed in way, that for adding new codec is not
> > > > needed to touch bluez5-util nor module-bluez5-device files. Whole
> > > > codec registration is done in a2dp-codec-util.c file, without need
> > > > to update any header file.
> > > > 
> > > > Some A2DP codecs are bidirectional and support backchannel for
> > > > microphone voice. This new A2DP codec API fully supports this feature
> > > > and module-bluez5-device was extended to support microphone voice source
> > > > for codecs which declares such support. FastStream is such codec.
> > > > 
> > > > For every A2DP codec is created card profile. When using bluez patches
> > > > from https://marc.info/?l=linux-bluetooth=154696260401673=2 then
> > > > only those profiles codec profiles are created which are supported
> > > > by remote headset/endpoint.
> > > 
> > > As discussed before, I don't think the codec configuration should be
> > > exposed via card profiles. There is need for being able to say "switch
> > > to A2DP" without specifying the codec.
> > 
> > I strongly agree with this. Separate profiles for each codec is simply not 
> > the way to go -- it's horrible for usability.
> 
> Why it is horrible?
> 
> I think horrible is when you need to introduce a new API into pulseaudio
> core for adding ability for switching to codec which supports
> microphone.
> 
> Same for having hardcoded priority list of codecs somewhere in config
> file or in module argument.
> 
> It would mean that switching to codec with microphone support cannot be
> done in existing GUI tools and it is needed to edit config file or
> re-load bluetooth module. This is horrible.

Perhaps my phrasing was a bit harsh, apologies if you found it so.

Having users to through a drop-down list for codec selection is unfriendly from 
a UX perspective was what I was getting at. For me this is a non-starter. For 
most people, this is configuration they don't and shouldn't care about. We 
should have sensible defaults and they should just work.

For people who do care, you're right, this is a gap in what PulseAudio 
currently supports. While we discuss a solution, a modarg allows us to take the 
existing work forward, especially since that configuration is only one 
independent part of whole.

I do not follow what you mean about codec with a microphone. If you mean A2DP 
source+sink at the same time with one of these codecs, I think this is not 
common enough to make everything else user unfriendly  and we can still try to 
find a way to enable it that doesn't require codec selection via profiles.

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

Re: [pulseaudio-discuss] [PATCH v5 0/7] New API for Bluetooth A2DP codecs

[Arun Raghavan]

On Fri, 25 Jan 2019, at 3:19 PM, Tanu Kaskinen wrote:
> On Sat, 2019-01-19 at 18:11 +0100, Pali Rohár wrote:
> > This is 5th version of my patch series for modular A2DP codec API and
> > aptX support. The only change for v5 is support for switching codecs.
> > 
> > This patch series provides new modular API for Bluetooth A2DP codecs,
> > clean up module-bluez5-device and bluez5-util to be codec independent
> > and convert SBC codec into this new API for A2DP codecs. Also it adds
> > support for aptX, aptX HD and FastStream A2DP codecs.
> > 
> > New codec API is designed in way, that for adding new codec is not
> > needed to touch bluez5-util nor module-bluez5-device files. Whole
> > codec registration is done in a2dp-codec-util.c file, without need
> > to update any header file.
> > 
> > Some A2DP codecs are bidirectional and support backchannel for
> > microphone voice. This new A2DP codec API fully supports this feature
> > and module-bluez5-device was extended to support microphone voice source
> > for codecs which declares such support. FastStream is such codec.
> > 
> > For every A2DP codec is created card profile. When using bluez patches
> > from https://marc.info/?l=linux-bluetooth=154696260401673=2 then
> > only those profiles codec profiles are created which are supported
> > by remote headset/endpoint.
> 
> As discussed before, I don't think the codec configuration should be
> exposed via card profiles. There is need for being able to say "switch
> to A2DP" without specifying the codec.

I strongly agree with this. Separate profiles for each codec is simply not the 
way to go -- it's horrible for usability.

> It's unclear how priority of the codecs (and their parameter
> permutations) should be configured, but it seems quite clear that a
> "set codec" operation on a specific card would be useful. If the "set
> codec" operation is separate from "set profile" operation, then you no
> doubt will ask how to implement the client API for this new operation,
> and I don't have a very good answer.
> 
> Georg Chini has been working on a new messaging API, which would be a
> good fit for this, but that's stalled (I don't remember if it's waiting
> for review or a new version of the patches). If you don't want to be
> blocked by that, the alternative is to add new "get bluetooth card
> info" and "set bluetooth card a2dp codec" commands to the core protocol
> (the card info command would be for enumerating the available codecs),
> or to add the commands via a new "protocol extension" similar to what
> module-stream-restore, module-device-restore and module-device-manager
> do. I would be fine with either approach.
> 
> Adding new commands to the core protocol would be somewhat simpler, but
> I'm not sure other maintainers are ok with adding bluetooth specific
> functionality to the core protocol.

I don't think adding this to the core is necessarily the best option, but I 
think this is a separate problem.

The current patchset should, imo, just take a priority-ordered list of codecs 
as a modarg and use that (we can choose some default if it is not specified, 
also ideally based on what codecs are supported on the system -- as I've 
suggested before, I don't want us to depend on the codec implementation, but I 
can help deal with that as a separate step).

So the modarg approach gives us a static configuration option for people who 
care about this setting immediately, with a sensible default for most of our 
users who will not. How we can make this runtime configurable can be figured 
out separately (for example, with Georg's on-going work).

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

Re: [pulseaudio-discuss] Revisiting 5.1/7.1 channel positions

[Arun Raghavan]

On Wed, 5 Dec 2018, at 5:26 PM, Tanu Kaskinen wrote:
> On Wed, 2018-12-05 at 16:39 +0530, Arun Raghavan wrote:
> > On Wed, 5 Dec 2018, at 3:59 PM, Tanu Kaskinen wrote:
> > > On Wed, 2018-12-05 at 15:08 +0530, Arun Raghavan wrote:
> > > > Hey folks,
> > > > I've written up a quick analysis of the channel positions we
> > > > currently support, and what I think makes sense:
> > > > 
> > > >   
> > > > https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/merge_requests/55#note_85318
> > > > 
> > > > The summary is that "Rear Left/Right" is currently being used in
> > > > place of what should be "Left/Right Surround", and we do not have any
> > > > channel  position between that position and "Rear Center", which is
> > > > needed for common 7.1 configurations (what would be "Rear Left/Right
> > > > Surround").
> > > > 
> > > > To add to this, the PulseAudio channelmap header is incorrect in that
> > > > we say that "Side Left/Right" should correspond to Dolby "Surround
> > > > Left/Right" when they are separate (they are further forward than
> > > > "Surround Left/Right". Yhis can be corrected easily enough as it's
> > > > just a documentation comment.
> > > > 
> > > > My proposal is to add a "Rear Left/Right of Center" position to
> > > > represent the missing positions. At the ALSA level, it would
> > > > correspond to RLC/RRC.
> > > > 
> > > > Any comments?
> > > 
> > > If I understood correctly, you're proposing that we should have three
> > > surround channel pairs (side, surround and rear) instead of two (side
> > > and rear). What practical problem would this solve?
> > > 
> > > I'm aware of the problem that some 5.1 streams use side and some use
> > > rear in their channel map specification (I don't know if there's any
> > > good reason for this), and up until very recently we didn't handle the
> > > side case properly. However, Alexander fixed this:
> > > https://gitlab.freedesktop.org/pulseaudio/pulseaudio/commit/73156649e76ac4000931990edcdcb3be31aade7b
> > 
> > In this case, the problem is that rear left/right means different
> > things based on the content.
> > 
> > For 5.1 content, you will use FL, FR, FC, RL, RR, LFE.
> > 
> > Now when you add 2 more channels for 7.1 content, those are supposed
> > to be further *behind* the 2 surround channels of 5.1, but we do not
> > have such channels. Which means we need to represent 7.1 content as
> > FL, FR, FC, SL, SR, RL, RR, LFE.
> > 
> > So Rear Left/Right means different things based on the content,
> > rather than have a somewhat fixed notion. This is illustrated in:
> > 
> >   
> > https://www.dolby.com/us/en/guide/dolby-atmos-speaker-setup/5-1-2-setups.html
> >   
> > https://www.dolby.com/us/en/guide/dolby-atmos-speaker-setup/7-1-2-setups.html
> 
> According to those illustrations, 5.1 surround channels are exactly the
> same thing as 7.1 side channels (based on the suggested 90-110 degree
> angle). So it would be logical to simply always use the side channels
> instead of the rear channels with 5.1, no need for introducing any new
> channel positions. Then there would be no ambiguity.
> 
> Clients for some reason sometimes use the side channels and sometimes
> the rear channels with 5.1 content. If that indicates a bug, the bug is
> in the clients (well, also in our 5.1 sink channel maps, because we use
> rear instead of side).

At this point, that "bug" is so ubiquitous, I don't think we can really change 
the fact that rear left/right really means surround left/right.

> > Also, notionally, for Dolby/DTS side left/right is a distinct set of
> > channels from surround left/right, though I'm not aware of whether
> > content that provides individual streams for those two sets of
> > channel exists (see page 82 of 
> > https://www.etsi.org/deliver/etsi_ts/102100_102199/102114/01.05.01_60/ts_102114v010501p.pdf
> > ).
> 
> That pdf defines these things:
> "surround on side", angle 90 degrees
> "surround on side in rear", angle 110 degrees
> "surround in rear", angle 150 degrees
> 
> The Dolby illustrations have just one pair of speakers for 90-110
> degrees in both 5.1 and 7.1 configurations, so to satisfy the ETSI
> table, a new channel wouldn't be needed further behind what we now call
> "rear" (which is what you 

Re: [pulseaudio-discuss] Revisiting 5.1/7.1 channel positions

[Arun Raghavan]

On Wed, 5 Dec 2018, at 3:59 PM, Tanu Kaskinen wrote:
> On Wed, 2018-12-05 at 15:08 +0530, Arun Raghavan wrote:
> > Hey folks,
> > I've written up a quick analysis of the channel positions we
> > currently support, and what I think makes sense:
> > 
> >   
> > https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/merge_requests/55#note_85318
> > 
> > The summary is that "Rear Left/Right" is currently being used in
> > place of what should be "Left/Right Surround", and we do not have any
> > channel  position between that position and "Rear Center", which is
> > needed for common 7.1 configurations (what would be "Rear Left/Right
> > Surround").
> > 
> > To add to this, the PulseAudio channelmap header is incorrect in that
> > we say that "Side Left/Right" should correspond to Dolby "Surround
> > Left/Right" when they are separate (they are further forward than
> > "Surround Left/Right". Yhis can be corrected easily enough as it's
> > just a documentation comment.
> > 
> > My proposal is to add a "Rear Left/Right of Center" position to
> > represent the missing positions. At the ALSA level, it would
> > correspond to RLC/RRC.
> > 
> > Any comments?
> 
> If I understood correctly, you're proposing that we should have three
> surround channel pairs (side, surround and rear) instead of two (side
> and rear). What practical problem would this solve?
> 
> I'm aware of the problem that some 5.1 streams use side and some use
> rear in their channel map specification (I don't know if there's any
> good reason for this), and up until very recently we didn't handle the
> side case properly. However, Alexander fixed this:
> https://gitlab.freedesktop.org/pulseaudio/pulseaudio/commit/73156649e76ac4000931990edcdcb3be31aade7b

In this case, the problem is that rear left/right means different things based 
on the content.

For 5.1 content, you will use FL, FR, FC, RL, RR, LFE.

Now when you add 2 more channels for 7.1 content, those are supposed to be 
further *behind* the 2 surround channels of 5.1, but we do not have such 
channels. Which means we need to represent 7.1 content as FL, FR, FC, SL, SR, 
RL, RR, LFE.

So Rear Left/Right means different things based on the content, rather than 
have a somewhat fixed notion. This is illustrated in:

  https://www.dolby.com/us/en/guide/dolby-atmos-speaker-setup/5-1-2-setups.html
  https://www.dolby.com/us/en/guide/dolby-atmos-speaker-setup/7-1-2-setups.html

Also, notionally, for Dolby/DTS side left/right is a distinct set of channels 
from surround left/right, though I'm not aware of whether content that provides 
individual streams for those two sets of channel exists (see page 82 of 
https://www.etsi.org/deliver/etsi_ts/102100_102199/102114/01.05.01_60/ts_102114v010501p.pdf).

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

[pulseaudio-discuss] Revisiting 5.1/7.1 channel positions

[Arun Raghavan]

Hey folks,
I've written up a quick analysis of the channel positions we currently support, 
and what I think makes sense:

  
https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/merge_requests/55#note_85318

The summary is that "Rear Left/Right" is currently being used in place of what 
should be "Left/Right Surround", and we do not have any channel  position 
between that position and "Rear Center", which is needed for common 7.1 
configurations (what would be "Rear Left/Right Surround").

To add to this, the PulseAudio channelmap header is incorrect in that we say 
that "Side Left/Right" should correspond to Dolby "Surround Left/Right" when 
they are separate (they are further forward than "Surround Left/Right". Yhis 
can be corrected easily enough as it's just a documentation comment.

My proposal is to add a "Rear Left/Right of Center" position to represent the 
missing positions. At the ALSA level, it would correspond to RLC/RRC.

Any comments?

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

Re: [pulseaudio-discuss] avoid-resampling -> avoid-processing

[Arun Raghavan]

On Fri, 26 Oct 2018, at 11:07 AM, Sangchul Lee wrote:
> 2018년 10월 25일 (목) 오후 11:34, Tanu Kaskinen 님이 작성:
> >
> > On Mon, 2018-10-15 at 09:59 +0530, Arun Raghavan wrote:
> > >
> > > On Thu, 27 Sep 2018, at 11:13 AM, Sangchul Lee wrote:
> > > > 2018년 9월 27일 (목) 오후 12:30, Arun Raghavan 님이 작성:
> > > > > On Wed, 26 Sep 2018, at 5:15 PM, Sangchul Lee wrote:
> > > > > > > > We could provide more fine-grained control (avoid-resampling/-
> > > > > > > > remapping/-conversion/-channel-mix), but I don't see the 
> > > > > > > > benefit of
> > > > > > > > this, so I figure a more overarching option is more likely to be
> > > > > > > > useful.
> > > > > > > >
> > > > > > > > Would be nice to hear people's thoughts on this.
> > > > > > >
> > > > > > > Having an "avoid-processing" option is a good idea. I'm not sure 
> > > > > > > what
> > > > > > > your proposal is for the old "avoid-resampling" option in 
> > > > > > > daemon.conf.
> > > > > > > I'd like to keep that separate, so that it only affects sample 
> > > > > > > rate
> > > > > > > conversion.
> > > > > >
> > > > > > I understood the backward compatibility you said. Do I need to 
> > > > > > modify
> > > > > > the patch expanding bit-depth("Consider sample format for
> > > > > > avoid-resampling/passthrough") with the new 'avoid-processing' 
> > > > > > option?
> > > > > > (I might upload a patch to the gitlab next time.)
> > > > >
> > > > > I've got a bunch of  changes waiting on top of hte existing 
> > > > > passthrough test MR. You probably should work off that. I've got the 
> > > > > changes at 
> > > > > https://gitlab.freedesktop.org/arun/pulseaudio/tree/reconfigure
> > > >
> > > > I checked commits on your local branch including replacing the option
> > > > name. It will be great to have the previous option with some logs for
> > > > guide according to the "The next best alternative" of tanu's opinion.
> > > >
> > > > And for now, I'll share V3 of "Consider sample format.." patch without
> > > > changing the name via email soon.
> > >
> > > I've implemented this feedback, some automated tests, and other review 
> > > comments in:
> > >
> > >   https://gitlab.freedesktop.org/pulseaudio/pulseaudio/merge_requests/24
> >
> > It's a bit unclear to me what the relationship between this MR and
> > "[PATCH v3] alsa-sink/source, sink, source: Consider sample format for
> > avoid-resampling/passthrough" is. Do you two have a common
> > understanding about which should be reviewed first?
> 
> This single patch is the last commit of my patch series for expanding
> 'avoid-' functionalities including checking with supported sample
> formats/rates and resetting hw param. And I think it is still needed
> even if the arun's MR which is wider rage - function parameter
> extension, channel-map things, renaming and null-sink modification -
> is merged. So I'd like to ask you to review this patch first(I think
> it is almost done..) and then rebase arun's MR 'if possible'.

I'm happy to rebase my work on top of this.

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

Re: [pulseaudio-discuss] avoid-resampling -> avoid-processing

[Arun Raghavan]

On Thu, 27 Sep 2018, at 11:13 AM, Sangchul Lee wrote:
> 2018년 9월 27일 (목) 오후 12:30, Arun Raghavan 님이 작성:
> >
> > On Wed, 26 Sep 2018, at 5:15 PM, Sangchul Lee wrote:
> > > > >
> > > > > We could provide more fine-grained control (avoid-resampling/-
> > > > > remapping/-conversion/-channel-mix), but I don't see the benefit of
> > > > > this, so I figure a more overarching option is more likely to be
> > > > > useful.
> > > > >
> > > > > Would be nice to hear people's thoughts on this.
> > > >
> > > > Having an "avoid-processing" option is a good idea. I'm not sure what
> > > > your proposal is for the old "avoid-resampling" option in daemon.conf.
> > > > I'd like to keep that separate, so that it only affects sample rate
> > > > conversion.
> > >
> > > I understood the backward compatibility you said. Do I need to modify
> > > the patch expanding bit-depth("Consider sample format for
> > > avoid-resampling/passthrough") with the new 'avoid-processing' option?
> > > (I might upload a patch to the gitlab next time.)
> >
> > I've got a bunch of  changes waiting on top of hte existing passthrough 
> > test MR. You probably should work off that. I've got the changes at 
> > https://gitlab.freedesktop.org/arun/pulseaudio/tree/reconfigure
> 
> I checked commits on your local branch including replacing the option
> name. It will be great to have the previous option with some logs for
> guide according to the "The next best alternative" of tanu's opinion.
> 
> And for now, I'll share V3 of "Consider sample format.." patch without
> changing the name via email soon.

I've implemented this feedback, some automated tests, and other review comments 
in:

  https://gitlab.freedesktop.org/pulseaudio/pulseaudio/merge_requests/24

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

Re: [pulseaudio-discuss] can rewindings in the null sink produce noises in programs recording its monitor?

[Arun Raghavan]

On Tue, 9 Oct 2018, at 1:57 PM, Tanu Kaskinen wrote:
> On Sat, 2018-10-06 at 15:29 -0300, wellington wallace wrote:
> > Hi! PulseEffects developer here again.
> > 
> > Like the title says I'd like to know if rewinds can cause crackling noises
> > when we are recording from a null sink monitor.
> 
> Yes it can: 
> https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/304
> 
> > In PulseEffecs I use the
> > plugin pulsesrc from GStreamer to record the null sink monitor and whenever
> > there is a change in the null sink volume or in the volume of a sink input
> > playing to the null sink I can here noises. Looking at Pulseaudio's logs I
> > can see lines with:
> > 
> > [null-sink] module-null-sink.c: Requested to rewind 3528 bytes.
> > [null-sink] sink.c: Processing rewind...
> > [null-sink] sink-input.c: Have to rewind 2840 bytes on render memblockq.
> > [null-sink] sink-input.c: Have to rewind 1420 bytes on implementor.
> > [null-sink] source.c: Processing rewind...
> > [null-sink] module-null-sink.c: Rewound 2840 bytes.
> > [pulseaudio] module-stream-restore.c: Storing volume/mute/device for stream
> > sink-input-by-media-role:music.
> > [pulseaudio] protocol-native.c: Client spotify changes volume of sink input
> > Spotify.
> > 
> > whenever the application volume is changed. At the same time they are shown
> > I can hear cracklings. So it seems related. I noticed that forcing pulsesrc
> > to use lower latencies help but do not fix the problem. Changing volumes
> > with pulsesrc latency-time parameter set to 1000 us produces less noises
> > than when it is set to 1 us.
> > 
> > I tried my best to see if there is anything I can do on my side to remove
> > this noise I found nothing. Is that how things are or is there anything
> > that can be done to remove this noises?
> 
> This is how things are. It would be great if someone would have a hard
> look at the monitor source rewinding code and see what goes wrong
> there.

I'd love it if someone beat me to it, but I think we need some unit testing for 
this.

In general, I've been trying to add some high-level utilities to allow us to 
write such tests easily, and we need to extend this to do a lot more:

  
https://gitlab.freedesktop.org/pulseaudio/pulseaudio/tree/master/src/tests/lo-test-util.h
  
https://gitlab.freedesktop.org/arun/pulseaudio/blob/reconfigure/src/tests/test-util.h

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

Re: [pulseaudio-discuss] avoid-resampling -> avoid-processing

[Arun Raghavan]

On Wed, 26 Sep 2018, at 5:15 PM, Sangchul Lee wrote:
> > >
> > > We could provide more fine-grained control (avoid-resampling/-
> > > remapping/-conversion/-channel-mix), but I don't see the benefit of
> > > this, so I figure a more overarching option is more likely to be
> > > useful.
> > >
> > > Would be nice to hear people's thoughts on this.
> >
> > Having an "avoid-processing" option is a good idea. I'm not sure what
> > your proposal is for the old "avoid-resampling" option in daemon.conf.
> > I'd like to keep that separate, so that it only affects sample rate
> > conversion.
> 
> I understood the backward compatibility you said. Do I need to modify
> the patch expanding bit-depth("Consider sample format for
> avoid-resampling/passthrough") with the new 'avoid-processing' option?
> (I might upload a patch to the gitlab next time.)

I've got a bunch of  changes waiting on top of hte existing passthrough test 
MR. You probably should work off that. I've got the changes at 
https://gitlab.freedesktop.org/arun/pulseaudio/tree/reconfigure

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

Re: [pulseaudio-discuss] Suggestions on how to support avoid-resampling on PulseEffects

[Arun Raghavan]

On Sun, 23 Sep 2018, at 6:57 AM, wellington wallace wrote:
> On Sat, Sep 22, 2018 at 9:17 PM Arun Raghavan  wrote:
> 
> >
> >
> > On Sat, 22 Sep 2018, at 10:03 PM, wellington wallace wrote:
> > > Hi PA developers!
> > >
> > > As you can see here https://github.com/wwmm/pulseeffects/issues/288
> > there
> > > are users that would like to have avoid-resampling supported in
> > > PulseEffects(and I would like it too). But honestly I am out of good
> > ideas
> > > about how to do this. At this moment I am using null sinks to do the
> > audio
> > > routing and there is a Gstreamer pipeline that records from it. I can
> > > change the format and rate of the GStreamer pipiline to the ones used by
> > > the audio application being processed but as I can't do the same to the
> > > null sink it would be pointless. The resampling would happen anyway.
> > >
> > > At this moment the only way I see to support avoid-resampling would be to
> > > reload the null sink with the new rate and format. But this is really
> > > annoying because as soon as I kill the null sink Pulseaudio will move the
> > > audio application back to the default device. It is not impossible to
> > deal
> > > with this. But it may require major changes in the code.
> > >
> > > Is reloading the null sink the only way to deal with this? It crossed my
> > > mind to try to make a custom null sink that could change these parameters
> > > on the fly. But besides the fact that Arch Linux packages do not have
> > > Pulseaudio developement headers I don't even know if it is possible to
> > make
> > > any null sink that would accept this.
> >
> > I have patches in the queue to enable reconfiguration for
> > module-null-sink.
> > https://gitlab.freedesktop.org/pulseaudio/pulseaudio/merge_requests/14
> >
> > Should be easy enough to add a modarg like we have for ALSA to make it
> > also just request support at module load time.
> >
> > -- Arun
> >
> 
> Hi Arun! These are very good news! So is the null sink going to
> automatically update its rate like it happens with the sound card sink when
> avoid-resampling is enabled? Or will it be necessary to take action using
> the libpulse api? Based on what I could understand of alsa-sink code it
> seems the first option. Assuming this to be the case is the sampling rate
> update going to trigger the "sink changed" event?
> 
> An automatic reconfiguration would welcome. This way I can focus only on
> the GStreamer pipeline and I wouldn't have different code paths for
> different Pulseaudio versions.

It's the latter. I don't think we emit a sink-changed, but we should.

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

Re: [pulseaudio-discuss] Suggestions on how to support avoid-resampling on PulseEffects

[Arun Raghavan]

On Sat, 22 Sep 2018, at 10:03 PM, wellington wallace wrote:
> Hi PA developers!
> 
> As you can see here https://github.com/wwmm/pulseeffects/issues/288 there
> are users that would like to have avoid-resampling supported in
> PulseEffects(and I would like it too). But honestly I am out of good ideas
> about how to do this. At this moment I am using null sinks to do the audio
> routing and there is a Gstreamer pipeline that records from it. I can
> change the format and rate of the GStreamer pipiline to the ones used by
> the audio application being processed but as I can't do the same to the
> null sink it would be pointless. The resampling would happen anyway.
> 
> At this moment the only way I see to support avoid-resampling would be to
> reload the null sink with the new rate and format. But this is really
> annoying because as soon as I kill the null sink Pulseaudio will move the
> audio application back to the default device. It is not impossible to deal
> with this. But it may require major changes in the code.
> 
> Is reloading the null sink the only way to deal with this? It crossed my
> mind to try to make a custom null sink that could change these parameters
> on the fly. But besides the fact that Arch Linux packages do not have
> Pulseaudio developement headers I don't even know if it is possible to make
> any null sink that would accept this.

I have patches in the queue to enable reconfiguration for module-null-sink. 
https://gitlab.freedesktop.org/pulseaudio/pulseaudio/merge_requests/14

Should be easy enough to add a modarg like we have for ALSA to make it also 
just request support at module load time.

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

Re: [pulseaudio-discuss] avoid-resampling -> avoid-processing

[Arun Raghavan]

On Fri, 21 Sep 2018, at 6:47 PM, Arun Raghavan wrote:
> On Fri, 21 Sep 2018, at 4:33 PM, Sangchul Lee wrote:
> > > I'm thinking that we should change the avoid resampling flag on sinks to 
> > > instead be avoid processing -- the idea being that we try not just to 
> > > reconfigure to a given sample rate, but for the entire sample spec (and 
> > > eventually channel map as well, once the reconfiguration patches are 
> > > updated to address Tanu's comments).
> > >
> > > The rationale is that I'd like to avoid having one more aspect of 
> > > configuration, and the use-case to avoid resampling almost certainly 
> > > applies to at least bit depth (16 <-> 24, usually) at least, and at that 
> > > point, why not everything.
> > >
> > > We could provide more fine-grained control 
> > > (avoid-resampling/-remapping/-conversion/-channel-mix), but I don't see 
> > > the benefit of this, so I figure a more overarching option is more likely 
> > > to be useful.
> > 
> > I agree with that. Although the pending patches(sorry to tanu, I'll
> > update soon that with applying your last comments :)) address
> > bit-depth within enabling 'avoid-resampling' option, I also think
> > changing the name to any other one is better than now.
> > (avoid-processing, avoid-resampler, or another one).
> 
> One question -- in avoid-resampling mode, we have a lower bound on the 
> sample rate (as the lowest of default and alternate sample rate). Should 
> we do the same thing for channels, or let the channel count be as low as 
> 1 if the media is so configured?
> 
> I have a mild leaning towards the latter as a sanity check.

Rethinking this, I think we should have a lower-bound defined by the 
sample-spec as a whole.

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

Re: [pulseaudio-discuss] avoid-resampling -> avoid-processing

[Arun Raghavan]

On Fri, 21 Sep 2018, at 4:33 PM, Sangchul Lee wrote:
> > I'm thinking that we should change the avoid resampling flag on sinks to 
> > instead be avoid processing -- the idea being that we try not just to 
> > reconfigure to a given sample rate, but for the entire sample spec (and 
> > eventually channel map as well, once the reconfiguration patches are 
> > updated to address Tanu's comments).
> >
> > The rationale is that I'd like to avoid having one more aspect of 
> > configuration, and the use-case to avoid resampling almost certainly 
> > applies to at least bit depth (16 <-> 24, usually) at least, and at that 
> > point, why not everything.
> >
> > We could provide more fine-grained control 
> > (avoid-resampling/-remapping/-conversion/-channel-mix), but I don't see the 
> > benefit of this, so I figure a more overarching option is more likely to be 
> > useful.
> 
> I agree with that. Although the pending patches(sorry to tanu, I'll
> update soon that with applying your last comments :)) address
> bit-depth within enabling 'avoid-resampling' option, I also think
> changing the name to any other one is better than now.
> (avoid-processing, avoid-resampler, or another one).

One question -- in avoid-resampling mode, we have a lower bound on the sample 
rate (as the lowest of default and alternate sample rate). Should we do the 
same thing for channels, or let the channel count be as low as 1 if the media 
is so configured?

I have a mild leaning towards the latter as a sanity check.

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

[pulseaudio-discuss] avoid-resampling -> avoid-processing

[Arun Raghavan]

Hello,
I'm thinking that we should change the avoid resampling flag on sinks to 
instead be avoid processing -- the idea being that we try not just to 
reconfigure to a given sample rate, but for the entire sample spec (and 
eventually channel map as well, once the reconfiguration patches are updated to 
address Tanu's comments).

The rationale is that I'd like to avoid having one more aspect of 
configuration, and the use-case to avoid resampling almost certainly applies to 
at least bit depth (16 <-> 24, usually) at least, and at that point, why not 
everything.

We could provide more fine-grained control 
(avoid-resampling/-remapping/-conversion/-channel-mix), but I don't see the 
benefit of this, so I figure a more overarching option is more likely to be 
useful.

Would be nice to hear people's thoughts on this.

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

Re: [pulseaudio-discuss] Bluetooth A2DP aptX codec quality

[Arun Raghavan]

On Wed, 12 Sep 2018, at 4:12 PM, Pali Rohár wrote:
> Hello!
> 
> I would like to let you know that Serge from soundexpert.org did in last
> month some research on aptX and its quality. Detailed article is on the
> following website, specially see parts added around "August 2018":
> 
> http://soundexpert.org/news/-/blogs/audio-quality-of-bluetooth-aptx
> 
> 
> Conclusions:
> 
> aptX codec used in BT applications is no better than SBC@328. Despite
> slightly lower algorithmic delay of aptX both SBC and aptX codecs
> provide the same 100-150ms latency in real-life BT applications.
> 
> If you hear the difference between SBC and aptX in some BT product,
> there can be only two explanations - placebo effect or using SBC in
> Middle or Low Quality modes.
> 
> 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)
> 
> 
> And it just confirms my own testing. Whatever I did I was not able to
> either hear or see difference between aptX and SBC encoded-->decoded
> audio.
> 
> I had discussion with Serge and there are some ideas which Linux
> Bluetooth A2DP software could supports:
> 
> 1) Allow user to specify SBC codec quality. In most cases, including
> pulseaudio, SBC quality is chosen either to middle or low, not to
> maximum bitpool. In some cases SBC at high quality can provide better
> quality as aptX and more important -- SBC is supported by all headsets.
> 
> 2) Show user current SBC codec quality. So user would know what was
> chosen and what should expect. I was told that Windows's Toshiba
> bluetooth stack has support for this indication.
> 
> 3) In some cases SBC SNR bit allocation method can provide better
> quality as SBC loudness method.

Thanks for sharing, this is very interesting.

> So then I could ask question:
> 
> 1) What to do with aptX? It is really useful for users to have it in
> Linux & pulseaudio? Because it looks like that the only thing which it
> has better is lower latency. But can pulseaudio on Linux system really
> achieve it?

What would prevent us from doing so?

> 2) Should we rather look at increasing quality of SBC codec in
> pulseaudio? And if yes, how should be quality of SBC configured? Via
> profiles? Or to invent some new protocol options? Can we increase
> default SBC bitpool allocation?

My preference is to not expose things to the user but try to move towards 

> 3) If aptX is decided as useless, what about aptX HD codec? aptX HD
> codec is supported by less products (currently I do not own any), but
> this one may provide better quality as SBC according to that research.

Right, could still be worth it indeed.

> PS: That aptX research is the first and the only one about which I know.
> All other information about quality or other details which I found on
> internet are just marking informations.

In general, it seems the work to support other codecs could still be valuable 
for AAC and maybe in the future, LDAC? Is anyone aware of a similar comparison 
for the either of these codecs?

AAC is still interesting for passthrough media, of course (I hope to have more 
on the ability to support that in coming weeks/months). Any objective 
information on LDAC would be interesting too.

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

Re: [pulseaudio-discuss] [PATCH v2 1/2] Modular API for Bluetooth A2DP codec

[Arun Raghavan]

On Tue, 4 Sep 2018, at 2:14 PM, Tanu Kaskinen wrote:
> Hi Pali!
> 
> Thanks a lot for working on this! Arun has been strongly advocating
> using GStreamer, and I don't know if his position is that "AptX must be
> implemented with GStreamer or not implemented at all". I hope not. To
> me the library choice is not important. Using libopenaptx directly
> doesn't prevent us from switching to GStreamer later if someone writes
> the code.

A couple of notes. Firstly, I really do appreciate all the work that Pali has 
put into this (it is clearly a lot).

Secondly, while I am dead against adding a codec as a dep, once we get things 
in shape where this is the only issue, I volunteer to help with the GStreamer 
bits so as to not block this.

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

[pulseaudio-discuss] Gitlab CI

[Arun Raghavan]

Hey folks,
I've now pushed and enabled CI for our gitlab instance. This  runs in an Ubuntu 
18.04-based docker image, Dockerfile is in scripts/. For now the image  is 
manually uploaded onto our fd.o docker registry, but it would be good to have 
that be automatically updated when the Dockerfile changes via CI.

I'm not removing the Travis yml yet, but am going to disable the Travis build 
as it is currently broken (because of old Ubuntu).

Fixes for the Travis build welcome (or better yet, for having Gitlab CI build 
with clang and push to Coverity, which are the only feature deltas).

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

Re: [pulseaudio-discuss] [PATCH] gitlab: Add support for GitLab CI

[Arun Raghavan]

On Thu, 23 Aug 2018, at 6:29 PM, Felipe Sateler wrote:
> On Wed, Aug 22, 2018 at 11:36 PM Arun Raghavan 
> wrote:
> 
> > This adds a Dockerfile to generate a Docker image with the required
> > dependencies on top of the standard Ubuntu 18.04 image. The Gitlab CI
> > then runs the PulseAudio build within this image.
> > ---
> >  .gitlab-ci.yml | 19 +
> >  scripts/Dockerfile | 53 ++
> >  2 files changed, 72 insertions(+)
> >  create mode 100644 .gitlab-ci.yml
> >  create mode 100644 scripts/Dockerfile
> >
> > diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> > new file mode 100644
> > index 0..e9c983075
> > --- /dev/null
> > +++ b/.gitlab-ci.yml
> > @@ -0,0 +1,19 @@
> > +image: registry.freedesktop.org/pulseaudio/pulseaudio/ubuntu:18.04
> > +
> > +build:
> > +  stage: build
> > +  script:
> > +- export MAKEFLAGS="-j4"
> >
> 
> This seems to be inappropriate for a CI build. How do you know the
> available cores in the runner? I would expect to have at most
> MAKEFLAGS=$(nproc)

Sure, can do.

> > +- NOCONFIGURE=1 ./bootstrap.sh
> > +- mkdir build
> > +- cd build
> > +- ../configure --localstatedir=/var
> >
> 
> I think for CI builds options should be explicitly selected, and have the
> build fail if any of the expected options cannot be enabled. This may help
> catch some configure.ac/Makefile.am bugs.

I'm okay to add that in if you have suggestions for a sensible list (imo this 
can come as a second step).

> > +- make
> > +- make check
> > +- make check-daemon
> > +- make distcheck
> >
> 
> This effectively runs make and make check again. I think it would be better
> to split this to a separate job so it can run in parallel.

Jobs require artifacts to be passed around, so it's a bit of a pain. I think 
the additional work is worth it for now, as distcheck caught the bug that I 
fixed in the last commit.

> > +- make install DESTDIR=`mktemp -d`
> > +- make dist
> > +  artifacts:
> > +paths:
> > +  - build/
> > diff --git a/scripts/Dockerfile b/scripts/Dockerfile
> > new file mode 100644
> > index 0..ed7063212
> > --- /dev/null
> > +++ b/scripts/Dockerfile
> > @@ -0,0 +1,53 @@
> > +# Start with current Ubuntu LTS
> > +FROM ubuntu:18.04
> > +
> > +# Add a PulseAudio's dependencies
> > +RUN apt-get update && apt-get install -y \
> > +autoconf \
> > +automake \
> > +autopoint \
> > +bash-completion \
> > +check \
> > +dbus-x11 \
> > +g++ \
> > +gcc \
> >
> 
> build-essential should get you a basic build system in place. Otherwise,
> you need to add make to the list (make might stop being a transitive
> dependency in the future).

I'll just add make in for now.

> > +gettext \
> >
> 
> Isn't intltool necessary too?(If not I could drop that from the debian
> package)

It got dropped as a dep with 57e3ccaf51f714eec8ca29005c3cc4fde456e84e.
 
> > +git-core \
> > +libasound2-dev \
> > +libasyncns-dev \
> > +libatomic-ops-dev \
> >
> 
> This is not necessary because gcc has atomic builtins.

Fair enough.

> > +libavahi-client-dev \
> > +libbluetooth-dev \
> > +libcap-dev \
> > +libfftw3-dev \
> > +libglib2.0-dev \
> > +libgtk-3-dev \
> > +libice-dev \
> > +libjack-dev \
> > +liblircclient-dev \
> > +libltdl-dev \
> > +liborc-0.4-dev \
> > +libsbc-dev \
> > +libsndfile1-dev \
> > +libsoxr-dev \
> > +libspeexdsp-dev \
> > +libssl-dev \
> > +libtdb-dev \
> > +libudev-dev \
> > +libwebrtc-audio-processing-dev \
> > +libwrap0-dev \
> > +libx11-xcb-dev \
> > +libxcb1-dev \
> > +libxml-parser-perl \
> > +libxtst-dev \
> > +systemd
> >
> 
> libsystemd-dev is missing.

We don't depend on libsystemd, just systemd.

> > +
> > +# Add a user and set as default for the build. This is safer, in general,
> > and
> > +# allows us to avoid having to explicitly allow running as root in the
> > +# check-daemon stage.
> > +RUN groupadd -g 1000 a_group && \
> > +useradd a_user -u 1000 -g a_group -m
> >
> 
> Ubuntu has adduser that creates both user and group at the same time.

Shouldn't matter as it's about the same (and more clear in some sense).

> > +USER a_user:a_group
> > +
> > +# And make sure subsequent commands are run in the user's home directory
> > +WORKDIR /home/a_user
> > --
> > 2.17.1
> >

Thanks for the review. I'll update the MR based on this and let's continue 
there.

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

[pulseaudio-discuss] [PATCH] gitlab: Add support for GitLab CI

[Arun Raghavan]

This adds a Dockerfile to generate a Docker image with the required
dependencies on top of the standard Ubuntu 18.04 image. The Gitlab CI
then runs the PulseAudio build within this image.
---
 .gitlab-ci.yml | 19 +
 scripts/Dockerfile | 53 ++
 2 files changed, 72 insertions(+)
 create mode 100644 .gitlab-ci.yml
 create mode 100644 scripts/Dockerfile

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
new file mode 100644
index 0..e9c983075
--- /dev/null
+++ b/.gitlab-ci.yml
@@ -0,0 +1,19 @@
+image: registry.freedesktop.org/pulseaudio/pulseaudio/ubuntu:18.04
+
+build:
+  stage: build
+  script:
+- export MAKEFLAGS="-j4"
+- NOCONFIGURE=1 ./bootstrap.sh
+- mkdir build
+- cd build
+- ../configure --localstatedir=/var
+- make
+- make check
+- make check-daemon
+- make distcheck
+- make install DESTDIR=`mktemp -d`
+- make dist
+  artifacts:
+paths:
+  - build/
diff --git a/scripts/Dockerfile b/scripts/Dockerfile
new file mode 100644
index 0..ed7063212
--- /dev/null
+++ b/scripts/Dockerfile
@@ -0,0 +1,53 @@
+# Start with current Ubuntu LTS
+FROM ubuntu:18.04
+
+# Add a PulseAudio's dependencies
+RUN apt-get update && apt-get install -y \
+autoconf \
+automake \
+autopoint \
+bash-completion \
+check \
+dbus-x11 \
+g++ \
+gcc \
+gettext \
+git-core \
+libasound2-dev \
+libasyncns-dev \
+libatomic-ops-dev \
+libavahi-client-dev \
+libbluetooth-dev \
+libcap-dev \
+libfftw3-dev \
+libglib2.0-dev \
+libgtk-3-dev \
+libice-dev \
+libjack-dev \
+liblircclient-dev \
+libltdl-dev \
+liborc-0.4-dev \
+libsbc-dev \
+libsndfile1-dev \
+libsoxr-dev \
+libspeexdsp-dev \
+libssl-dev \
+libtdb-dev \
+libudev-dev \
+libwebrtc-audio-processing-dev \
+libwrap0-dev \
+libx11-xcb-dev \
+libxcb1-dev \
+libxml-parser-perl \
+libxtst-dev \
+systemd
+
+# Add a user and set as default for the build. This is safer, in general, and
+# allows us to avoid having to explicitly allow running as root in the
+# check-daemon stage.
+RUN groupadd -g 1000 a_group && \
+useradd a_user -u 1000 -g a_group -m
+USER a_user:a_group
+
+# And make sure subsequent commands are run in the user's home directory
+WORKDIR /home/a_user
-- 
2.17.1

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

Re: [pulseaudio-discuss] [PATCH v2 0/2] Bluetooth A2DP aptX codec support

[Arun Raghavan]

On Fri, 3 Aug 2018, at 7:13 PM, ValdikSS wrote:
> On 03.08.2018 16:32, Pali Rohár wrote:
> > On Friday 03 August 2018 16:22:05 ValdikSS wrote:
> >> Doesn't work for me with Intel 7260 Bluetooth 4.0 and RealForce OverDrive 
> >> D1.
> >>
> >> When I connect headphones and change Pulseaudio profile from "Off" to 
> >> "High Fidelity SBC playback (a2dp sink)", everything works as expected 
> >> with SBC.
> >> Profile does not switch if I choose "High Fidelity aptX playback (a2dp 
> >> sink)" when SBC profile is already active, log message:
> >>
> >> W: [pulseaudio] module-bluez5-device.c: Refused to switch profile to 
> >> a2dp_aptx_sink: Not connected
> > Profile switching does not work -- bluez does not provide API for it.
> >
> > Codec is chosen by bluez and headset when doing handshake. Try to
> > initialize A2DP connection from computer, not from headset. Then bluez
> > should choose aptX codec in case your headset supports it.
> 
> Works now:
>   AVDTP: Set Configuration (0x03) Command (0x00) type 0x00 label 10 nosp 0
>     ACP SEID: 5
>     INT SEID: 1
>     Service Category: Media Transport (0x01)
>     Service Category: Media Codec (0x07)
>   Media Type: Audio (0x00)
>   Media Codec: Non-A2DP (0xff)
>     Vendor ID: APT Licensing Ltd. (0x004f)
>     Vendor Specific Codec ID: aptX (0x0001)
>   Frequency: 44100 (0x20)
>   Channel Mode: Stereo (0x02)
> 
> >
> >> When I try to switch to aptX profile from "off" profile, pulseaudio 
> >> crashes:
> >>
> >> E: [pulseaudio] module-bluez5-device.c: Assertion '!u->thread' failed at 
> >> modules/bluetooth/module-bluez5-device.c:1491, function start_thread(). 
> >> Aborting.
> > Try:
> >
> > $ pactl unload-module module-bluetooth-policy
> >
> > Seems that policy module needs to be fixed for new aptx profiles.
> 
> That works, thanks.
> 
> >
> >> Thread 1 "pulseaudio" received signal SIGABRT, Aborted.
> >> 0x744edfeb in raise () from /lib64/libc.so.6
> >> (gdb) bt
> >> #0  0x744edfeb in raise () from /lib64/libc.so.6
> >> #1  0x744d85c1 in abort () from /lib64/libc.so.6
> >> #2  0x7fff7f3dab45 in start_thread (u=u@entry=0x5593d640) at 
> >> modules/bluetooth/module-bluez5-device.c:1491
> >> #3  0x7fff7f3dd263 in set_profile_cb (c=, 
> >> new_profile=0x559251a0) at 
> >> modules/bluetooth/module-bluez5-device.c:1859
> >> #4  0x77b5148e in pa_card_set_profile (c=c@entry=0x558e4c20, 
> >> profile=profile@entry=0x559251a0, save=save@entry=true) at 
> >> pulsecore/card.c:318
> >> #5  0x7fffe0a0362d in command_set_card_profile (pd=, 
> >> command=, tag=127, t=, userdata= >> out>) at pulsecore/protocol-native.c:4728
> >> #6  0x76d83813 in pa_pdispatch_run (pd=0x55a2e4b0, 
> >> packet=packet@entry=0x558a3020, 
> >> ancil_data=ancil_data@entry=0x55975bf8, 
> >> userdata=userdata@entry=0x558bebf0) at pulsecore/pdispatch.c:346
> >> #7  0x7fffe0a0bee9 in pstream_packet_callback (p=0x55975960, 
> >> packet=0x558a3020, ancil_data=0x55975bf8, userdata=0x558bebf0) 
> >> at pulsecore/protocol-native.c:4951
> >> #8  0x76d8629d in do_read (p=p@entry=0x55975960, 
> >> re=re@entry=0x55975b28) at pulsecore/pstream.c:1012
> >> #9  0x76d890eb in do_pstream_read_write (p=0x55975960) at 
> >> pulsecore/pstream.c:248
> >> #10 0x76d8949d in srb_callback (srb=0x558b0660, 
> >> userdata=0x55975960) at pulsecore/pstream.c:287
> >> #11 0x76d89d2a in srbchannel_rwloop (sr=0x558b0660) at 
> >> pulsecore/srbchannel.c:190
> >> #12 0x778fc8a8 in dispatch_pollfds (m=0x5576f120) at 
> >> pulse/mainloop.c:140
> >> #13 pa_mainloop_dispatch (m=m@entry=0x5576f120) at pulse/mainloop.c:898
> >> #14 0x778fcb80 in pa_mainloop_iterate (m=0x5576f120, 
> >> block=, retval=0x7fffdc18) at pulse/mainloop.c:929
> >> #15 0x778fcc20 in pa_mainloop_run (m=0x5576f120, 
> >> retval=0x7fffdc18) at pulse/mainloop.c:945
> >> #16 0xb0c9 in main (argc=, argv= >> out>) at daemon/main.c:1144
> >>
> >>
> >> I haven't installed any patches for bluez itself. Should I? If yes, which 
> >> exactly?
> > There are no bluez patches.
> >
> >> I moved libopenaptx to autotools and made Fedora .spec file for openaptx, 
> >> are you interested in autotools support for libopenaptx, should I create a 
> >> pull request to your repository?
> > Nope, I'm not interested to use autohell, simple Makefile for simple
> > library is enough :-) Basically I see no reason for conversion to tool
> > which then just generate Makefile back.
> 
> I don't like autotools either, but it make packaging much easier since 
> all distros support autotools packaging almost automatically. It also 
> handles shared/static libraries, libtool, different paths and cross-
> compilation with just configure flags.
> It would be maintenance burden to package library with a 

Re: [pulseaudio-discuss] [PATCH v2 1/2] Modular API for Bluetooth A2DP codec

[Arun Raghavan]

On Sat, 28 Jul 2018, at 9:04 PM, Pali Rohár wrote:
> Move current SBC codec implementation into separate source file and use
> this new API for providing all needed functionality for Bluetooth A2DP.
> 
> Both bluez5-util and module-bluez5-device are changed to use this new
> modular codec API.
> ---
>  src/Makefile.am  |   9 +-
>  src/modules/bluetooth/a2dp-codecs.h  |   5 +-
>  src/modules/bluetooth/bluez5-util.c  | 331 +--
>  src/modules/bluetooth/bluez5-util.h  |  10 +-
>  src/modules/bluetooth/module-bluez5-device.c | 487 ++
>  src/modules/bluetooth/pa-a2dp-codec-sbc.c| 579 
> +++
>  src/modules/bluetooth/pa-a2dp-codec.h|  40 ++
>  7 files changed, 851 insertions(+), 610 deletions(-)
>  create mode 100644 src/modules/bluetooth/pa-a2dp-codec-sbc.c
>  create mode 100644 src/modules/bluetooth/pa-a2dp-codec.h
> 
> diff --git a/src/Makefile.am b/src/Makefile.am
> index f62e7d5c4..411b9e5e5 100644
> --- a/src/Makefile.am
> +++ b/src/Makefile.am
> @@ -2117,6 +2117,7 @@ module_bluetooth_discover_la_CFLAGS = $(AM_CFLAGS) 
> -DPA_MODULE_NAME=module_bluet
>  libbluez5_util_la_SOURCES = \
>   modules/bluetooth/bluez5-util.c \
>   modules/bluetooth/bluez5-util.h \
> + modules/bluetooth/pa-a2dp-codec.h \
>   modules/bluetooth/a2dp-codecs.h
>  if HAVE_BLUEZ_5_OFONO_HEADSET
>  libbluez5_util_la_SOURCES += \
> @@ -2131,6 +2132,10 @@ libbluez5_util_la_LDFLAGS = -avoid-version
>  libbluez5_util_la_LIBADD = $(MODULE_LIBADD) $(DBUS_LIBS)
>  libbluez5_util_la_CFLAGS = $(AM_CFLAGS) $(DBUS_CFLAGS)
>  
> +libbluez5_util_la_SOURCES += modules/bluetooth/pa-a2dp-codec-sbc.c
> +libbluez5_util_la_LIBADD += $(SBC_LIBS)
> +libbluez5_util_la_CFLAGS += $(SBC_CFLAGS)
> +
>  module_bluez5_discover_la_SOURCES = modules/bluetooth/module-bluez5-
> discover.c
>  module_bluez5_discover_la_LDFLAGS = $(MODULE_LDFLAGS)
>  module_bluez5_discover_la_LIBADD = $(MODULE_LIBADD) $(DBUS_LIBS) 
> libbluez5-util.la
> @@ -2138,8 +2143,8 @@ module_bluez5_discover_la_CFLAGS = $(AM_CFLAGS) $
> (DBUS_CFLAGS) -DPA_MODULE_NAME=
>  
>  module_bluez5_device_la_SOURCES = modules/bluetooth/module-bluez5-
> device.c
>  module_bluez5_device_la_LDFLAGS = $(MODULE_LDFLAGS)
> -module_bluez5_device_la_LIBADD = $(MODULE_LIBADD) $(SBC_LIBS) 
> libbluez5-util.la
> -module_bluez5_device_la_CFLAGS = $(AM_CFLAGS) $(SBC_CFLAGS) -
> DPA_MODULE_NAME=module_bluez5_device
> +module_bluez5_device_la_LIBADD = $(MODULE_LIBADD) libbluez5-util.la
> +module_bluez5_device_la_CFLAGS = $(AM_CFLAGS) -
> DPA_MODULE_NAME=module_bluez5_device
>  
>  # Apple Airtunes/RAOP
>  module_raop_sink_la_SOURCES = modules/raop/module-raop-sink.c
> diff --git a/src/modules/bluetooth/a2dp-codecs.h b/src/modules/
> bluetooth/a2dp-codecs.h
> index 8afcfcb24..004975586 100644
> --- a/src/modules/bluetooth/a2dp-codecs.h
> +++ b/src/modules/bluetooth/a2dp-codecs.h
> @@ -47,6 +47,9 @@
>  #define SBC_ALLOCATION_SNR   (1 << 1)
>  #define SBC_ALLOCATION_LOUDNESS  1
>  
> +#define SBC_MIN_BITPOOL 2
> +#define SBC_MAX_BITPOOL 64
> +
>  #define MPEG_CHANNEL_MODE_MONO   (1 << 3)
>  #define MPEG_CHANNEL_MODE_DUAL_CHANNEL   (1 << 2)
>  #define MPEG_CHANNEL_MODE_STEREO (1 << 1)
> @@ -63,8 +66,6 @@
>  #define MPEG_SAMPLING_FREQ_44100 (1 << 1)
>  #define MPEG_SAMPLING_FREQ_48000 1
>  
> -#define MAX_BITPOOL 64
> -#define MIN_BITPOOL 2
>  
>  #if __BYTE_ORDER == __LITTLE_ENDIAN
>  
> diff --git a/src/modules/bluetooth/bluez5-util.c b/src/modules/
> bluetooth/bluez5-util.c
> index 2d8337317..9c4e3367b 100644
> --- a/src/modules/bluetooth/bluez5-util.c
> +++ b/src/modules/bluetooth/bluez5-util.c
> @@ -2,6 +2,7 @@
>This file is part of PulseAudio.
>  
>Copyright 2008-2013 João Paulo Rechi Vita
> +  Copyrigth 2018  Pali Rohár 
>  
>PulseAudio is free software; you can redistribute it and/or modify
>it under the terms of the GNU Lesser General Public License as
> @@ -33,7 +34,7 @@
>  #include 
>  #include 
>  
> -#include "a2dp-codecs.h"
> +#include "pa-a2dp-codec.h"
>  
>  #include "bluez5-util.h"
>  
> @@ -48,8 +49,8 @@
>  
>  #define BLUEZ_ERROR_NOT_SUPPORTED "org.bluez.Error.NotSupported"
>  
> -#define A2DP_SOURCE_ENDPOINT "/MediaEndpoint/A2DPSource"
> -#define A2DP_SINK_ENDPOINT "/MediaEndpoint/A2DPSink"
> +#define A2DP_SOURCE_SBC_ENDPOINT "/MediaEndpoint/A2DPSourceSBC"
> +#define A2DP_SINK_SBC_ENDPOINT "/MediaEndpoint/A2DPSinkSBC"
>  
>  #define ENDPOINT_INTROSPECT_XML 
> \
>  DBUS_INTROSPECT_1_0_XML_DOCTYPE_DECL_NODE   
> \
> @@ -170,9 +171,9 @@ static const char 
> *transport_state_to_string(pa_bluetooth_transport_state_t stat
>  
>  static bool device_supports_profile(pa_bluetooth_device *device, 
> pa_bluetooth_profile_t profile) {
>  switch (profile) {
> -case PA_BLUETOOTH_PROFILE_A2DP_SINK:
> +case 

Re: [pulseaudio-discuss] Moving to GitLab

[Arun Raghavan]

On Mon, 30 Jul 2018, at 5:20 PM, Arun Raghavan wrote:
> On Fri, 27 Jul 2018, at 6:43 PM, Arun Raghavan wrote:
> > On Wed, 25 Jul 2018, at 5:25 PM, Arun Raghavan wrote:
> > > Hi folks,
> > > The freedesktop admins have now started helping projects move to GitLab 
> > > (http://gitlab.freedesktop.org/) on a pilot basis. I'm quite excited 
> > > about this as it would mean a better way to track patches, as well as a 
> > > more familiar interface for new contributors coming from the Github 
> > > world.
> > > 
> > > The choices are to move piecemeal (git + merge requests first, bugs 
> > > later), or just do it all at one shot. I favour the latter, in the 
> > > spirit of absorbing all the migration pain at one shot. This is probably 
> > > a good time in the release cycle to do this as well. There's a tracker 
> > > bug for getting this done at:
> > > 
> > >   https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/49
> > > 
> > > Thoughts? Questions?
> > > 
> > > As a first step, I would request everyone with commit access to set up 
> > > your account and populate your key(s).
> > 
> > We're moving ahead with this. Subscribe to the bug above to keep track 
> > of progress, and I'll send out an update as the big changes happen.
> 
> And this is done!
> 
> The organisation is at: https://gitlab.freedesktop.org/pulseaudio
> 
> Existing open bugs have been migrated, and new issues should be filed 
> against the relevant project (for example 
> https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues)
> 
> We are also transitioning from patches sent to the mailing list to MRs 
> (merge requests). The simple description of the workflow is that you 
> create a fork using the GitLab UI, create a branch, push your changes, 
> and then get back to the web UI which will let you create a merge 
> request from your fork/branch. (more details at 
> https://docs.gitlab.com/ee/gitlab-basics/add-merge-request.html)
> 
> That's it. Please chime in if you have questions/comments.

Please note that while pulseaudio-commits will continue to get commit emails, 
pulseaudio-bugs will no longer be functional. You can just go and to the GitLab 
UI and "Watch" the PulseAudio group (or any repo / issue within it) to get the 
same effeect.

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

Re: [pulseaudio-discuss] Bluetooth aptX codec

[Arun Raghavan]

On Mon, 30 Jul 2018, at 5:14 PM, Pali Rohár wrote:
> On Monday 30 July 2018 17:04:55 Arun Raghavan wrote:
> > On Mon, 30 Jul 2018, at 12:42 PM, Pali Rohár wrote:
> > [...]
> > > I looked and there is absolutely nothing about A2DP codec parameter
> > > selections. So really does not help.
> > 
> > Okay, I feel like this conversation has been us talking past each other, so 
> > let me try to summarise what I'm saying more clearly:
> > 
> > 1. The BlueZ modules will, possibly based on modargs, expose a set of 
> > supported codecs. Yes, that includes codec parameters, the knowledge of 
> > which the endpoint needs to have. If you have ideas for making this 
> > modular, I'm open to suggestions.
> > 
> > 2. For the specific process of RTP payload/depayload and selection of a 
> > codec implementation for encode/decode, I believe we should construct and 
> > use a GStreamer bin, so as to not have to offload that choice to the system 
> > integrator rather than having to make that choice in PulseAudio. I feel 
> > strongly enough about not linking to specific codec implementations that 
> > any approach that does that is a NACK from me. I realise we already have 
> > this for SBC, but I do not want to add any more.
> 
> Look at my last (v2) patch series for aptX. Here I created some
> modularisation of codecs and addition of another codecs would be easier.

Will do. Note that I'm not just talk about modularity w.r.t. codecs, but also 
codec implementations.

> I have not used Gstreamer as it does not help me -- it does not provide
> module for A2DP codec negotiation (it is not static list of parameters
> as you imagine, but negotiation function) nor it does not support aptX
> codec.

That's still not problematic from a GStreamer perspective. It is possible to 
set up parameters via caps if needed after the negotiation stage. And wrapping 
your library in a GStreamer plugin would be a trivial effort.

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

Re: [pulseaudio-discuss] Moving to GitLab

[Arun Raghavan]

On Fri, 27 Jul 2018, at 6:43 PM, Arun Raghavan wrote:
> On Wed, 25 Jul 2018, at 5:25 PM, Arun Raghavan wrote:
> > Hi folks,
> > The freedesktop admins have now started helping projects move to GitLab 
> > (http://gitlab.freedesktop.org/) on a pilot basis. I'm quite excited 
> > about this as it would mean a better way to track patches, as well as a 
> > more familiar interface for new contributors coming from the Github 
> > world.
> > 
> > The choices are to move piecemeal (git + merge requests first, bugs 
> > later), or just do it all at one shot. I favour the latter, in the 
> > spirit of absorbing all the migration pain at one shot. This is probably 
> > a good time in the release cycle to do this as well. There's a tracker 
> > bug for getting this done at:
> > 
> >   https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/49
> > 
> > Thoughts? Questions?
> > 
> > As a first step, I would request everyone with commit access to set up 
> > your account and populate your key(s).
> 
> We're moving ahead with this. Subscribe to the bug above to keep track 
> of progress, and I'll send out an update as the big changes happen.

And this is done!

The organisation is at: https://gitlab.freedesktop.org/pulseaudio

Existing open bugs have been migrated, and new issues should be filed against 
the relevant project (for example 
https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues)

We are also transitioning from patches sent to the mailing list to MRs (merge 
requests). The simple description of the workflow is that you create a fork 
using the GitLab UI, create a branch, push your changes, and then get back to 
the web UI which will let you create a merge request from your fork/branch. 
(more details at 
https://docs.gitlab.com/ee/gitlab-basics/add-merge-request.html)

That's it. Please chime in if you have questions/comments.

Cheers,
Arun

p.s.: My heartfelt thanks to Daniel Stone and the freedesktop.org admin team 
for the super quick migration.
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Bluetooth aptX codec

[Arun Raghavan]

On Mon, 30 Jul 2018, at 12:42 PM, Pali Rohár wrote:
[...]
> I looked and there is absolutely nothing about A2DP codec parameter
> selections. So really does not help.

Okay, I feel like this conversation has been us talking past each other, so let 
me try to summarise what I'm saying more clearly:

1. The BlueZ modules will, possibly based on modargs, expose a set of supported 
codecs. Yes, that includes codec parameters, the knowledge of which the 
endpoint needs to have. If you have ideas for making this modular, I'm open to 
suggestions.

2. For the specific process of RTP payload/depayload and selection of a codec 
implementation for encode/decode, I believe we should construct and use a 
GStreamer bin, so as to not have to offload that choice to the system 
integrator rather than having to make that choice in PulseAudio. I feel 
strongly enough about not linking to specific codec implementations that any 
approach that does that is a NACK from me. I realise we already have this for 
SBC, but I do not want to add any more.

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

Re: [pulseaudio-discuss] Bluetooth aptX codec

[Arun Raghavan]

On Sat, 28 Jul 2018, at 9:01 PM, Pali Rohár wrote:
> On Monday 23 July 2018 18:42:52 Arun Raghavan wrote:
> > On Sun, 8 Jul 2018, at 12:14 AM, Pali Rohár wrote:
> > > On Sunday 08 July 2018 01:44:39 Alexander E. Patrakov wrote:
> > > > сб, 7 июл. 2018 г. в 19:08, Pali Rohár :
> > > > >
> > > > > On Saturday 07 July 2018 09:39:53 Arun Raghavan wrote:
> > > > > > Pre-installed doesn't mean much tbh. It is easy enough for packages 
> > > > > > to depend on it.
> > > > >
> > > > > Can pulseaudio build process enforce it?
> > 
> > Does not need to, that can be taken care of at packaging time, and 
> > potentially at module load.
> 
> Ok, I would ask differently: Can pulseaudio at packaging time enforce it?

That depends on the packaging system, but broadly the answer is yes.

> > > > 2. GStreamer can, in theory, wrap the needed libraries, and does
> > > > support third-party plugins, but does not properly encapsulate the
> > > > "give me packets ready to send via bluez" part.
> > > 
> > > And until this is supported by external library (ffmpeg, gstreamer,
> > > whatever), pulseaudio needs to implement it itself.
> > > 
> > > And encapsulating encoded data for bluez is not enough. It is needed
> > > also to negotiate codec selection with bluez and codec parameters (which
> > > are codec specific).
> > 
> > GStreamer has RTP payloading for sbc, mp3 and aac, so that can easily be 
> > used (and again, less codec-specific stuff that needs to be in PA).
> 
> But it does not solve above problem when it is needed to do A2DP codec
> selection and negotiation.

I don't get what you mean here.

> > > In previous email I wrote about idea to move that codec stuff into bluez
> > > itself as bluez code already handles it for android.
> > > 
> > > > >
> > > > > > > To have working bluetooth support in pulseadio, pulseaudio needs 
> > > > > > > to use
> > > > > > > external library for encoding which *always* provides support for 
> > > > > > > SBC.
> > > > > > > And not only if user manually installs some special plugin for 
> > > > > > > 3rd party
> > > > > > > library. (And not only SBC, but also those other aptX, MPEG1/2, 
> > > > > > > AAC and
> > > > > > > LDAC codecs)
> > > > > >
> > > > > > So I continue to disagree. Using a generic framework and letting 
> > > > > > other parts of the system select the codec implementation is what 
> > > > > > makes sense for the widest set of use-cases (this also allows 
> > > > > > products to ship their own implementations of a codec without 
> > > > > > changing the PulseAudio code).
> > > > >
> > > > > Still this is not enough for bluetooth codec. For specific codec you
> > > > > need to create bluez dbus endpoint with codec specific parameters. 
> > > > > Plus
> > > > > implement select and set methods to decide on codec parameters between
> > > > > pulseaudio and bluetooth headset. And finally to send encoded data you
> > > > > need to know how to send them. To which endpoint, how header looks 
> > > > > like
> > > > > etc... Some codecs needs to wrap data into RTP (e.g. SBC), some must 
> > > > > not
> > > > > have RTP (e.g. aptX). And after that comes data from codec encoder
> > > > > function.
> > > > >
> > > > > So is there any library which all above support? I have not find
> > > > > anything. Nor ffmpeg nor gstreamer.
> > > > >
> > > > > Which means that pulseaudio cannot delegate codec selection, codec
> > > > > initialization and codec encoding to some external library (yet).
> > 
> > At least for SBC and presumably AAC, this is all possible with GStreamer
> 
> No, it is not possible -- or at least I have not found any way how. I
> spend more time with it and Gstreamer does not support it. If you still
> think that it is possible, post a gstreamer code or link how to do that.

Look at the rtpsbcpay/rtpsbcdepay elements, for example.

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

Re: [pulseaudio-discuss] Moving to GitLab

[Arun Raghavan]

On Wed, 25 Jul 2018, at 5:25 PM, Arun Raghavan wrote:
> Hi folks,
> The freedesktop admins have now started helping projects move to GitLab 
> (http://gitlab.freedesktop.org/) on a pilot basis. I'm quite excited 
> about this as it would mean a better way to track patches, as well as a 
> more familiar interface for new contributors coming from the Github 
> world.
> 
> The choices are to move piecemeal (git + merge requests first, bugs 
> later), or just do it all at one shot. I favour the latter, in the 
> spirit of absorbing all the migration pain at one shot. This is probably 
> a good time in the release cycle to do this as well. There's a tracker 
> bug for getting this done at:
> 
>   https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/49
> 
> Thoughts? Questions?
> 
> As a first step, I would request everyone with commit access to set up 
> your account and populate your key(s).

We're moving ahead with this. Subscribe to the bug above to keep track of 
progress, and I'll send out an update as the big changes happen.

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

Re: [pulseaudio-discuss] [PATCH paprefs 0/8] Remove autotools and update README

[Arun Raghavan]

On Wed, 25 Jul 2018, at 7:20 PM, Tanu Kaskinen wrote:
> The README patches are the same that I submitted earlier with a couple
> of changes: the news section now mentions that autotools has been
> replaced with meson, and one commit message needed tweaking now that
> we've had a couple of PulseAudio releases after 12.0.
> 
> Tanu Kaskinen (8):
>   remove the autotools build system
>   README: remove the copyright notice
>   README: add "Bug Reports" and "Contributing Code" sections
>   README: remove the "Acknowledgements" section
>   README: add a news item for the upcoming release
>   README: remove reference to an ancient Debian version
>   README: clarify the PulseAudio version requirement
>   README: remove the page footer
> 
>  .gitignore | 28 --
>  Makefile.am| 61 --
>  autogen.sh | 24 
>  bootstrap.sh   | 67 -
>  configure.ac   | 93 --
>  doc/.gitignore |  2 -
>  doc/README.html.in | 35 +
>  po/.gitignore  | 13 ---
>  src/.gitignore |  2 -
>  src/Makefile.am| 42 -
>  10 files changed, 17 insertions(+), 350 deletions(-)
>  delete mode 100644 Makefile.am
>  delete mode 100755 autogen.sh
>  delete mode 100755 bootstrap.sh
>  delete mode 100644 configure.ac
>  delete mode 100644 doc/.gitignore
>  delete mode 100644 po/.gitignore
>  delete mode 100644 src/.gitignore
>  delete mode 100644 src/Makefile.am
> 
> -- 

Looks good to me.

Packagers, now is the time to scream if you have objections!

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

[pulseaudio-discuss] Updating review policy for trivial patches

[Arun Raghavan]

Hi folks,
Given limited review bandwidth, we're moving to a discretionary skipping of 
review of trivial patches (yes, trivial is subjective, but hopefully not _too_ 
subjective :) ).

I believe that anything that gets missed in these cases can be picked up by 
those of us reviewing pulseaudio-commits.

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