Re: [pulseaudio-discuss] [PATCH v13 05/10] bluetooth: Add A2DP aptX and aptX HD codecs support

[Andrey Semashev]

On 2019-10-06 20:58, Pali Rohár wrote:

This patch provides support for aptX and aptX HD codecs in bluetooth A2DP
profile. It uses open source LGPLv2.1+ licensed libopenaptx library which
can be found at https://github.com/pali/libopenaptx.

aptX for s24 stereo samples provides fixed 6:1 compression ratio and
bitrate 352.8 kbit/s, aptX HD provides fixed 4:1 compression ratio and
bitrate 529.2 kbit/s.

According to soundexpert research, aptX codec used in bluetooth A2DP is no
better than SBC High Quality settings. And you cannot hear difference
between aptX and SBC High Quality, aptX is just a copper-less overpriced
audio cable.

aptX HD is high-bitrate version of aptX. It has clearly noticeable increase
in sound quality (not dramatic though taking into account the increase in
bitrate).

http://soundexpert.org/news/-/blogs/audio-quality-of-bluetooth-aptx
---
  configure.ac|  36 +++
  src/Makefile.am |   6 +
  src/modules/bluetooth/a2dp-codec-aptx.c | 479 
  src/modules/bluetooth/a2dp-codec-util.c |   8 +
  4 files changed, 529 insertions(+)
  create mode 100644 src/modules/bluetooth/a2dp-codec-aptx.c


[snip]


+
+static 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) {
+struct aptx_context *aptx_c = (struct aptx_context *) codec_info;
+size_t written;
+
+*processed = aptx_encode(aptx_c, input_buffer, input_size, output_buffer, 
output_size, );
+if (PA_UNLIKELY(*processed == 0 || *processed != input_size))
+pa_log_error("aptX encoding error");
+
+return written;
+}
+
+static size_t encode_buffer_hd(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 aptx_hd_info *aptx_hd_info = (struct aptx_hd_info *) codec_info;
+struct rtp_header *header;
+size_t written;
+
+if (PA_UNLIKELY(output_size < sizeof(*header))) {
+*processed = 0;
+return 0;
+}
+
+written = encode_buffer(aptx_hd_info->aptx_c, timestamp, input_buffer, 
input_size, output_buffer + sizeof(*header), output_size - sizeof(*header), 
processed);
+
+if (PA_LIKELY(written > 0)) {
+header = (struct rtp_header *) output_buffer;


I'm not sure I understand it correctly, but encode_buffer seems to be 
producing encoded content at the beginning of the output buffer, and 
encode_buffer_hd produces an RTP header followed by encoded content. Is 
this difference intentional? What is expected to be placed in the output 
buffer - a complete RTP packet or RTP payload only?


The same comment applies to decode_buffer and decode_buffer_hd below.


+pa_zero(*header);
+header->v = 2;
+header->pt = 96;
+header->sequence_number = htons(aptx_hd_info->seq_num++);
+header->timestamp = htonl(timestamp);
+header->ssrc = htonl(1);
+written += sizeof(*header);
+}
+
+return written;
+}
+
+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 aptx_context *aptx_c = (struct aptx_context *) codec_info;
+size_t written;
+
+*processed = aptx_decode(aptx_c, input_buffer, input_size, output_buffer, 
output_size, );
+
+/* Due to aptX latency, aptx_decode starts filling output buffer after 90 
input samples.
+ * If input buffer contains less than 90 samples, aptx_decode returns zero 
(=no output)
+ * but set *processed to non zero as input samples were processed. So do 
not check for
+ * return value of aptx_decode, zero is valid. Decoding error is 
indicating by fact that
+ * not all input samples were processed. */
+if (PA_UNLIKELY(*processed != input_size))
+pa_log_error("aptX decoding error");
+
+return written;
+}
+
+static size_t decode_buffer_hd(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 aptx_hd_info *aptx_hd_info = (struct aptx_hd_info *) codec_info;
+struct rtp_header *header;
+size_t written;
+
+if (PA_UNLIKELY(input_size < sizeof(*header))) {
+*processed = 0;
+return 0;
+}
+
+header = (struct rtp_header *) input_buffer;
+written = decode_buffer(aptx_hd_info->aptx_c, timestamp, input_buffer + 
sizeof(*header), input_size - sizeof(*header), output_buffer, output_size, 
processed);
+*timestamp = ntohl(header->timestamp);
+*processed += sizeof(*header);
+return written;
+}

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

Re: [pulseaudio-discuss] SBC XQ for PA 13.0

[Andrey Semashev]

On 2019-12-09 15:57, Hyperion wrote:



09.12.2019, 12:33, "Andrey Semashev" :

I have another piece of feedback to provide. Sometimes I experience
audio dropouts. Sometimes in both left and right headphones, sometimes
just one. In particular, I noticed this happen when I have a
Bluetooth-connected DualShock 4 gamepad connected and playing games, but
it also happens without it, although less often.

I assume this is caused by Bluetooth bandwidth limitation. Note that EOZ
Air are "truly wireless" (i.e. the two headphones connect wirelessly),
and I have multiple WiFi networks available (one access point in the
same room as the Bluetooth transmitter, a few others behind walls). I
expect 2.4 GHz radio to be rather crowded. The gamepad and the
headphones are in the same room as the Bluetooth transmitter, in clear
direct visibility, so it can't get better than that.

I can see Pali's patches offer reduce_encoder_bitrate API that is
supposed to mitigate this problem, but both SBC XQ profiles don't allow
bitrate reduction. I think, SBC XQ desperately needs to support bitrate
reduction, as the codec with the highest bitrate out of all.


Yes, and my patch was providing 100% adaptative SBC XQ, with native bitpool
reduction, as you suggest.


Is this adaptation implemented in

https://github.com/JPGuillemin/pulseaudio/commit/0853d7465729c1fb6c25745c05dc749a1b9a8d6f

? If so, then either the audio dropouts I experience are caused by 
something other than bandwidth limitation, or the adaptation isn't 
working or helping.

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

Re: [pulseaudio-discuss] SBC XQ for PA 13.0

[Andrey Semashev]

On 2019-12-09 15:53, Hyperion wrote:



09.12.2019, 12:47, "Andrey Semashev" :

On 2019-12-09 14:39, Pali Rohár wrote:

  On Monday 09 December 2019 14:32:52 Andrey Semashev wrote:

  I have another piece of feedback to provide. Sometimes I experience audio
  dropouts. Sometimes in both left and right headphones, sometimes just one.
  In particular, I noticed this happen when I have a Bluetooth-connected
  DualShock 4 gamepad connected and playing games, but it also happens without
  it, although less often.

  I assume this is caused by Bluetooth bandwidth limitation. Note that EOZ Air
  are "truly wireless" (i.e. the two headphones connect wirelessly), and I
  have multiple WiFi networks available (one access point in the same room as
  the Bluetooth transmitter, a few others behind walls). I expect 2.4 GHz
  radio to be rather crowded. The gamepad and the headphones are in the same
  room as the Bluetooth transmitter, in clear direct visibility, so it can't
  get better than that.


  Yes, 2.4 GHz is shared by both Bluetooth and WiFi, so it may be a
  problem.


  I can see Pali's patches offer reduce_encoder_bitrate API that is supposed
  to mitigate this problem, but both SBC XQ profiles don't allow bitrate
  reduction.


  Yes, SBC XQ is there the highest available quality profile of SBC.


  I think, SBC XQ desperately needs to support bitrate reduction,


  No, this is main reason for usage of SBC XQ it is high quality codec.
  SBC XQ needs high bitrate by its definition.


  as the codec with the highest bitrate out of all. Users might actually have
  reduced experience due to audio dropouts compared to the previously
  supported SBC HQ.


  If you cannot use high bitrate codecs, then do not use high bitrate
  codecs. There are other profiles of SBC which lower bitpool value and
  therefore lower bitrate. E.g. SBC MQ or SBC LQ (medium and low quality).

  Or you can use SBC in automatic mode where bitrate is automatically
  decreased.


As a user, I don't know whether I can use SBC XQ. I don't know whether
its bitrate will fit in my radio conditions. If my device happens to
support SBC XQ, that is the codec that will get picked upon connection.
Please, correct me if I'm wrong, but I don't see a way to influence that.

SBC XQ is high quality and high bitrate, true, but PA should adapt to
the actual use conditions. More so if it actually has the means to do
so. If PA detects that SBC XQ does not fit in BT bandwidth, it should
gradually drop quality.


Please take a look at the many discussions, experiments, specifications 
analysis and calculations about
SBC XQ, before posting this kind of complaint. You make devs waste a lot of 
time at this point of implementation.


Can you point me to these discussions?

Also, I'm providing feedback based on the actual usage experience, which 
is something you asked for. The devs can disregard it if they choose so, 
I just don't think this would be for the benefit of PA user experience.

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

Re: [pulseaudio-discuss] SBC XQ for PA 13.0

[Andrey Semashev]

On 2019-12-09 14:56, Pali Rohár wrote:

On Monday 09 December 2019 14:47:26 Andrey Semashev wrote:

As a user, I don't know whether I can use SBC XQ. I don't know whether its
bitrate will fit in my radio conditions. If my device happens to support SBC
XQ, that is the codec that will get picked upon connection. Please, correct
me if I'm wrong, but I don't see a way to influence that.


You can ask same question for aptX-HD codec. It has also fixed high
bitrate.


If there is no way to switch between aptX-HD and aptX without device 
reconnection then that's a limitation of this particular codec and 
there's nothing we can do about it. This is not the case for SBC, if I 
understand correctly.



SBC XQ is high quality and high bitrate, true, but PA should adapt to the
actual use conditions.


SBC XQ is defined with usage of one specific bitpool value.


Correct me if I'm wrong, but regardless of the quality there is only one 
codec defined by A2DP - SBC. A2DP also defines several bitpool values 
that should be used for this codec, which are commonly called LQ, MQ and 
HQ. XQ is not formally defined by A2DP, but is actually supported by 
devices. If all this is correct, I don't see why PA couldn't switch 
between XQ and HQ the same way it switches from HQ to MQ in automatic mode.



More so if it actually has the means to do so. If PA
detects that SBC XQ does not fit in BT bandwidth, it should gradually drop
quality.


Maybe we can implement disconnecting SBC XQ profile when problem happen
and connect again with SBC in Automatic quality.


I'm not sure I understand the technical details of this, but if it 
happens transparently to the user then that would be fine.



But there is another problem. People who chose high quality codec do not
want to see that application itself without their instruction decide to
change codec to low quality. This is reason why non-SBC codecs are used.
Because they provide one fixed quality which is same whatever bluetooth
adapter or headphone you will use. SBC is criticized for a long time
because current implementations automatically choose some quality which
is not under user control. So for these reasons there is SBC LQ, MQ, HQ
and XQ. You can choose what you want to use. By default is automatic
mode which decreasing quality.


I think the main criticism toward SBC is poor quality. A fair deal of 
that criticism is misattributed to the codec itself and in fact is 
caused by poor implementation in devices. But I can be reasonably sure 
that for an average user signal stability always comes first, and 
quality second.


I don't mind if there is a way to force a specific quality profile or 
codec in PA. In fact, that would probably be useful for working around 
various problems (e.g. when a device declares it supports XQ but 
actually doesn't work). However, in the automatic mode, which should be 
the default, XQ should be no different from the other profiles and 
participate in quality adaptation.

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

Re: [pulseaudio-discuss] SBC XQ for PA 13.0

[Andrey Semashev]

On 2019-12-09 14:39, Pali Rohár wrote:

On Monday 09 December 2019 14:32:52 Andrey Semashev wrote:

I have another piece of feedback to provide. Sometimes I experience audio
dropouts. Sometimes in both left and right headphones, sometimes just one.
In particular, I noticed this happen when I have a Bluetooth-connected
DualShock 4 gamepad connected and playing games, but it also happens without
it, although less often.

I assume this is caused by Bluetooth bandwidth limitation. Note that EOZ Air
are "truly wireless" (i.e. the two headphones connect wirelessly), and I
have multiple WiFi networks available (one access point in the same room as
the Bluetooth transmitter, a few others behind walls). I expect 2.4 GHz
radio to be rather crowded. The gamepad and the headphones are in the same
room as the Bluetooth transmitter, in clear direct visibility, so it can't
get better than that.


Yes, 2.4 GHz is shared by both Bluetooth and WiFi, so it may be a
problem.


I can see Pali's patches offer reduce_encoder_bitrate API that is supposed
to mitigate this problem, but both SBC XQ profiles don't allow bitrate
reduction.


Yes, SBC XQ is there the highest available quality profile of SBC.


I think, SBC XQ desperately needs to support bitrate reduction,


No, this is main reason for usage of SBC XQ it is high quality codec.
SBC XQ needs high bitrate by its definition.


as the codec with the highest bitrate out of all. Users might actually have
reduced experience due to audio dropouts compared to the previously
supported SBC HQ.


If you cannot use high bitrate codecs, then do not use high bitrate
codecs. There are other profiles of SBC which lower bitpool value and
therefore lower bitrate. E.g. SBC MQ or SBC LQ (medium and low quality).

Or you can use SBC in automatic mode where bitrate is automatically
decreased.


As a user, I don't know whether I can use SBC XQ. I don't know whether 
its bitrate will fit in my radio conditions. If my device happens to 
support SBC XQ, that is the codec that will get picked upon connection. 
Please, correct me if I'm wrong, but I don't see a way to influence that.


SBC XQ is high quality and high bitrate, true, but PA should adapt to 
the actual use conditions. More so if it actually has the means to do 
so. If PA detects that SBC XQ does not fit in BT bandwidth, it should 
gradually drop quality.

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

Re: [pulseaudio-discuss] SBC XQ for PA 13.0

[Andrey Semashev]

I have another piece of feedback to provide. Sometimes I experience 
audio dropouts. Sometimes in both left and right headphones, sometimes 
just one. In particular, I noticed this happen when I have a 
Bluetooth-connected DualShock 4 gamepad connected and playing games, but 
it also happens without it, although less often.


I assume this is caused by Bluetooth bandwidth limitation. Note that EOZ 
Air are "truly wireless" (i.e. the two headphones connect wirelessly), 
and I have multiple WiFi networks available (one access point in the 
same room as the Bluetooth transmitter, a few others behind walls). I 
expect 2.4 GHz radio to be rather crowded. The gamepad and the 
headphones are in the same room as the Bluetooth transmitter, in clear 
direct visibility, so it can't get better than that.


I can see Pali's patches offer reduce_encoder_bitrate API that is 
supposed to mitigate this problem, but both SBC XQ profiles don't allow 
bitrate reduction. I think, SBC XQ desperately needs to support bitrate 
reduction, as the codec with the highest bitrate out of all. Users might 
actually have reduced experience due to audio dropouts compared to the 
previously supported SBC HQ.


On 2019-12-07 21:09, Andrey Semashev wrote:
FWIW, I tested the patch[1] from your github repository with PulseAudio 
13.0 on Ubuntu 19.10 with my EOZ Air. It works, and the sound quality is 
subjectively better compared to the stock PA 13.0. The noise level that 
can be heard on silent audio sections seems to be lower.


However, I can still hear compression artefacts on quiet or nearly 
silent audio sections, which sound like high-pitch squeaking sounds. It 
can often be heard on various music fade out sections. I don't know if 
this is inherrent from SBC codec itself or is a deficiency of libsbc 
implementation, or the headphones. These artefacts are my main complaint 
about SBC.


My EOZ Air also supports AAC, and the audio quality is better still with 
it (I tested with pulseaudio-modules-bt[2] and my Android phone). There 
are no squeaky artefacts with AAC.


Which brings me to my question to PA developers. Would an addition of 
support for AAC be possible?


pulseaudio-modules-bt uses libfdk-aac to implement AAC, and if possible, 
I would prefer that library as it provides the best quality available on 
Linux. However, if licensing is an issue, there is also a built-in 
implementation in ffmpeg.


[1]: Patch obtained with `git diff 
200618b32f0964a479d69c9b6e5073e6931c370a..0853d7465729c1fb6c25745c05dc749a1b9a8d6f` 


[2]: https://github.com/EHfive/pulseaudio-modules-bt


On 2019-09-20 12:45, Hyperion wrote:

HI,

I have reworked my mod so that it can safely achieve bitpool 94 in 
both dual channel and joint stereo, as long as the device supports it 
(only my high end Harman Kardon support 94 in joint stereo).
Devices supporting only bitpool 53 are kept safe (bitpool is always 
negociated, never forced : this doesn't use fixed caps).


Anyway most devices support at least bitpool 47 in dual channel mode, 
and BT (version 3 and up) bandwidth is much higher : so this patch 
deprecates both APTX and LDAC.


The Git is up to date : https://github.com/JPGuillemin/pulseaudio

This patch is likely safe to be applied on the official master cause 
it doesn't need Bluez multi-codec API, and doesn't introduce any 
patent issue (mainly from CSR, openaptx being underground reverse 
ingeniering).


All the best
JP

19.09.2019, 13:07, "Hyperion" :
The Git branch with my mods : 
https://github.com/JPGuillemin/pulseaudio/tree/SBC-XQ


I'm sure it needs improvement, but I need testers ;) for now it works 
as expected on all my devices...


JP

19.09.2019, 11:21, "Hyperion" :
  Yes, thanks, you're right, I'm going to do it as soon as I get 
enough testing feedback.


  Talking about tests : I'm going to switch back to Pali's default 
values for announced bitpool capabilities, cause some (rare) devices 
produces a few distorsion with dual channel 47 bitpool.


  So back to dual 38 / 76 , which should be ok on any device.

  New patch : 
http://download.zenwalk.org/x86_64/testing/pulseaudio-13.0-SBC-XQ_V3.patch 



  Thanks for testing :)

  jp

  19.09.2019, 10:27, "Andrey Semashev" :
   I'm not the maintainer, but it might be better to create a merge 
request

   in GitLab project:

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

   and post any additional information there so it doesn't get lost.

   On 2019-09-18 14:02, Hyperion wrote:

Patch V2 with added DUAL_CHANNEL as preferred mode.

Works without any issue on more than 10 stereo and mono 
devices that I have here.


http://download.zenwalk.org/x86_64/testing/pulseaudio-13.0-SBC-XQ_V2.patch 



/***
   This file is part of PulseAudio.

   Copyright 2018-2019 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 

Re: [pulseaudio-discuss] SBC XQ for PA 13.0

[Andrey Semashev]

On 2019-12-08 21:00, Pali Rohár wrote:

On Sunday 08 December 2019 20:40:09 Andrey Semashev wrote:


One other question regarding libfdk-aac. Would it be ok to try using it
through ffmpeg if it is built with it? If ffmpeg is compiled without
libfdk-aac then we would fall back to the built-in encoder.

This would allow people who build ffmpeg themselves to use libfdk-aac. On
the PA side, this would require very little change code-wise (it would not
introduce build dependency on libfdk-aac), most of the integration with
ffmpeg remains the same.


Supported A2DP codecs needs to be know at pulseaudio compile time.
So unsupported codecs are excluded from build. This is also needed to
ensure that compile time flags make sense and prevent problems that user
compiled pulseaudio with codec X, but X does not work because is not
installed available in system. So in pulseaudio's ELF binary are
correctly filled all libraries and its codecs via NEEDED flag (which is
used for generating dependences for probably all package managers).


The configure script will verify that ffmpeg is available and supports 
AAC. Whether it is built with libfdk-aac or not is not important at this 
stage because the built-in AAC encoder is always available. The attempt 
to use libfdk-aac (through ffmpeg API) will be performed at run time, 
and if it fails, we will use the built-in encoder.


Package dependencies are not a problem, PA packages will depend on 
libavcodec (not on libfdk-aac). Which will most probably be a virtual 
package, which is provided by one of the variants of libavcodec. For 
example, on Debian systems there are libavcodec58 and libavcodec58-extra 
(the latter provides more codecs), and either of them can be installed 
by user to fulfill the dependency on libavcodec.

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

Re: [pulseaudio-discuss] SBC XQ for PA 13.0

[Andrey Semashev]

On 2019-12-07 22:31, Pali Rohár wrote:

On Saturday 07 December 2019 22:13:28 Andrey Semashev wrote:

On 2019-12-07 21:30, Pali Rohár wrote:


FDK-AAC library is incompatible with any version of the GNU GPL license
and therefore it is not possible to use it in any GPL licensed software,
like pulseaudio. See: https://www.gnu.org/licenses/license-list.html#fdk


Well, incompatibility means the resulting binary is not redistributable.
Users could still build PA with libfdk-aac locally.


Yes, you are right.


Or the library could be
loaded dynamically, if present on the user's system, without having to link
with it at build time.


Some people says that this is not legal too. Loading library either at
build (link) time is same as at runtime... And FSF has similar
explanation. Main problem is that license of external library does not
allow you to use it in your application. And it does not depend on how
you build your application or how you use that library (dlopen or
stating or dynamic linking). You are still usage same library API. But
I'm not lawyer...

Important it that if there are people who doubt about regular usage then
such functionality would not be included into distribution. And above
dynamic loading via dlopen is a reason for doubt that something is not
there fully legal and can be problematic.


If there is other AAC library which license allows usage it in
pulseaudio then it could be possible. Just somebody needs to write it.


The built-in implementation in ffmpeg is under LGPL 2.1, which should be
compatible.


Yes, LGPL 2.1 is fine.


One other question regarding libfdk-aac. Would it be ok to try using it 
through ffmpeg if it is built with it? If ffmpeg is compiled without 
libfdk-aac then we would fall back to the built-in encoder.


This would allow people who build ffmpeg themselves to use libfdk-aac. 
On the PA side, this would require very little change code-wise (it 
would not introduce build dependency on libfdk-aac), most of the 
integration with ffmpeg remains the same.

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

Re: [pulseaudio-discuss] SBC XQ for PA 13.0

[Andrey Semashev]

On 2019-12-07 21:30, Pali Rohár wrote:

On Saturday 07 December 2019 21:09:04 Andrey Semashev wrote:

However, I can still hear compression artefacts on quiet or nearly silent
audio sections, which sound like high-pitch squeaking sounds. It can often
be heard on various music fade out sections. I don't know if this is
inherrent from SBC codec itself or is a deficiency of libsbc implementation,
or the headphones. These artefacts are my main complaint about SBC.


See very nice description about this problem https://habr.com/en/post/456182/
Probably your headphones cripple audio by filters when SBC is used...


Yes, I've read that. That is the reason why I suspect the headphones 
might be the culprit, but I cannot be sure.



Which brings me to my question to PA developers. Would an addition of
support for AAC be possible?


My A2DP patch series brings new pulseaudio API for implementing new A2DP
codecs. So yes, additional support for other A2DP codecs with my patch
series is possible. My patch series contains support for aptX, aptX-HD
and FastStream A2DP codecs.


Are your patches available in a PR or a git fork somewhere? If I'm going 
to give it a try to add support for AAC, how can I get the up to date PA 
version to develop against?



But... you need a library for encoding and decoding that codec ...


pulseaudio-modules-bt uses libfdk-aac to implement AAC, and if possible, I
would prefer that library as it provides the best quality available on
Linux. However, if licensing is an issue, there is also a built-in
implementation in ffmpeg.


FDK-AAC library is incompatible with any version of the GNU GPL license
and therefore it is not possible to use it in any GPL licensed software,
like pulseaudio. See: https://www.gnu.org/licenses/license-list.html#fdk


Well, incompatibility means the resulting binary is not redistributable. 
Users could still build PA with libfdk-aac locally. Or the library could 
be loaded dynamically, if present on the user's system, without having 
to link with it at build time.



If there is other AAC library which license allows usage it in
pulseaudio then it could be possible. Just somebody needs to write it.


The built-in implementation in ffmpeg is under LGPL 2.1, which should be 
compatible.

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

Re: [pulseaudio-discuss] SBC XQ for PA 13.0

[Andrey Semashev]

FWIW, I tested the patch[1] from your github repository with PulseAudio 
13.0 on Ubuntu 19.10 with my EOZ Air. It works, and the sound quality is 
subjectively better compared to the stock PA 13.0. The noise level that 
can be heard on silent audio sections seems to be lower.


However, I can still hear compression artefacts on quiet or nearly 
silent audio sections, which sound like high-pitch squeaking sounds. It 
can often be heard on various music fade out sections. I don't know if 
this is inherrent from SBC codec itself or is a deficiency of libsbc 
implementation, or the headphones. These artefacts are my main complaint 
about SBC.


My EOZ Air also supports AAC, and the audio quality is better still with 
it (I tested with pulseaudio-modules-bt[2] and my Android phone). There 
are no squeaky artefacts with AAC.


Which brings me to my question to PA developers. Would an addition of 
support for AAC be possible?


pulseaudio-modules-bt uses libfdk-aac to implement AAC, and if possible, 
I would prefer that library as it provides the best quality available on 
Linux. However, if licensing is an issue, there is also a built-in 
implementation in ffmpeg.


[1]: Patch obtained with `git diff 
200618b32f0964a479d69c9b6e5073e6931c370a..0853d7465729c1fb6c25745c05dc749a1b9a8d6f`

[2]: https://github.com/EHfive/pulseaudio-modules-bt


On 2019-09-20 12:45, Hyperion wrote:

HI,

I have reworked my mod so that it can safely achieve bitpool 94 in both dual 
channel and joint stereo, as long as the device supports it (only my high end 
Harman Kardon support 94 in joint stereo).
  
Devices supporting only bitpool 53 are kept safe (bitpool is always negociated, never forced : this doesn't use fixed caps).


Anyway most devices support at least bitpool 47 in dual channel mode, and BT 
(version 3 and up) bandwidth is much higher : so this patch deprecates both 
APTX and LDAC.

The Git is up to date : https://github.com/JPGuillemin/pulseaudio

This patch is likely safe to be applied on the official master cause it doesn't 
need Bluez multi-codec API, and doesn't introduce any patent issue (mainly from 
CSR, openaptx being underground reverse ingeniering).

All the best
JP

19.09.2019, 13:07, "Hyperion" :

The Git branch with my mods : 
https://github.com/JPGuillemin/pulseaudio/tree/SBC-XQ

I'm sure it needs improvement, but I need testers ;) for now it works as 
expected on all my devices...

JP

19.09.2019, 11:21, "Hyperion" :

  Yes, thanks, you're right, I'm going to do it as soon as I get enough testing 
feedback.

  Talking about tests : I'm going to switch back to Pali's default values for 
announced bitpool capabilities, cause some (rare) devices produces a few 
distorsion with dual channel 47 bitpool.

  So back to dual 38 / 76 , which should be ok on any device.

  New patch : 
http://download.zenwalk.org/x86_64/testing/pulseaudio-13.0-SBC-XQ_V3.patch

  Thanks for testing :)

  jp

  19.09.2019, 10:27, "Andrey Semashev" :

   I'm not the maintainer, but it might be better to create a merge request
   in GitLab project:

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

   and post any additional information there so it doesn't get lost.

   On 2019-09-18 14:02, Hyperion wrote:

    Patch V2 with added DUAL_CHANNEL as preferred mode.

    Works without any issue on more than 10 stereo and mono devices that I have 
here.

    http://download.zenwalk.org/x86_64/testing/pulseaudio-13.0-SBC-XQ_V2.patch

    /***
   This file is part of PulseAudio.

   Copyright 2018-2019 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
   published by the Free Software Foundation; either version 2.1 of the
   License, or (at your option) any later version.

   PulseAudio is distributed in the hope that it will be useful, but
   WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
   General Public License for more details.

   You should have received a copy of the GNU Lesser General Public
   License along with PulseAudio; if not, see 
<http://www.gnu.org/licenses/>.
    ***/

    #ifdef HAVE_CONFIG_H
    #include 
    #endif

    #include 
    #include 
    #include 
    #include 
    #include 
    #include 

    #include 

    #include 

    #include "a2dp-codecs.h"
    #include "a2dp-codec-api.h"
    #include "rtp.h"

    #define SBC_BITPOOL_DEC_LIMIT 32
    #define SBC_BITPOOL_DEC_STEP 5

    struct sbc_info {
 sbc_t sbc; /* Codec data */
 size_t codesize, frame_length; /* SBC Codesize, frame_length. We 
simply cache those values here */
 uint16_t seq_num; /* Cumulative packet sequence */
 uint8_t frequency;
 uint8_t blocks;
 uint8_t subbands;
 uint8_t mode;
 uint

Re: [pulseaudio-discuss] SBC XQ for PA 13.0

[Andrey Semashev]

I'm not the maintainer, but it might be better to create a merge request 
in GitLab project:


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

and post any additional information there so it doesn't get lost.

On 2019-09-18 14:02, Hyperion wrote:

Patch V2 with added DUAL_CHANNEL as preferred mode.

Works without any issue on more than 10 stereo and mono devices that I have 
here.

http://download.zenwalk.org/x86_64/testing/pulseaudio-13.0-SBC-XQ_V2.patch

/***
   This file is part of PulseAudio.

   Copyright 2018-2019 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
   published by the Free Software Foundation; either version 2.1 of the
   License, or (at your option) any later version.

   PulseAudio is distributed in the hope that it will be useful, but
   WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
   General Public License for more details.

   You should have received a copy of the GNU Lesser General Public
   License along with PulseAudio; if not, see .
***/

#ifdef HAVE_CONFIG_H
#include 
#endif

#include 
#include 
#include 
#include 
#include 
#include 

#include 

#include 

#include "a2dp-codecs.h"
#include "a2dp-codec-api.h"
#include "rtp.h"

#define SBC_BITPOOL_DEC_LIMIT 32
#define SBC_BITPOOL_DEC_STEP 5

struct sbc_info {
 sbc_t sbc;   /* Codec data */
 size_t codesize, frame_length;   /* SBC Codesize, frame_length. We 
simply cache those values here */
 uint16_t seq_num;/* Cumulative packet sequence */
 uint8_t frequency;
 uint8_t blocks;
 uint8_t subbands;
 uint8_t mode;
 uint8_t allocation;
 uint8_t initial_bitpool;
 uint8_t min_bitpool;
 uint8_t max_bitpool;
};

static bool can_accept_capabilities(const uint8_t *capabilities_buffer, uint8_t 
capabilities_size, bool for_encoding) {
 const a2dp_sbc_t *capabilities = (const a2dp_sbc_t *) capabilities_buffer;

 if (capabilities_size != sizeof(*capabilities))
 return false;

 if (!(capabilities->frequency & (SBC_SAMPLING_FREQ_16000 | 
SBC_SAMPLING_FREQ_32000 | SBC_SAMPLING_FREQ_44100 | SBC_SAMPLING_FREQ_48000)))
 return false;

 if (!(capabilities->channel_mode & (SBC_CHANNEL_MODE_MONO | 
SBC_CHANNEL_MODE_DUAL_CHANNEL | SBC_CHANNEL_MODE_STEREO | 
SBC_CHANNEL_MODE_JOINT_STEREO)))
 return false;

 if (!(capabilities->allocation_method & (SBC_ALLOCATION_SNR | 
SBC_ALLOCATION_LOUDNESS)))
 return false;

 if (!(capabilities->subbands & (SBC_SUBBANDS_4 | SBC_SUBBANDS_8)))
 return false;

 if (!(capabilities->block_length & (SBC_BLOCK_LENGTH_4 | 
SBC_BLOCK_LENGTH_8 | SBC_BLOCK_LENGTH_12 | SBC_BLOCK_LENGTH_16)))
 return false;

 return true;
}

static const char *choose_remote_endpoint(const pa_hashmap 
*capabilities_hashmap, const pa_sample_spec *default_sample_spec, bool 
for_encoding) {
 const pa_a2dp_codec_capabilities *a2dp_capabilities;
 const char *key;
 void *state;

 /* There is no preference, just choose random valid entry */
 PA_HASHMAP_FOREACH_KV(key, a2dp_capabilities, capabilities_hashmap, state) 
{
 if (can_accept_capabilities(a2dp_capabilities->buffer, 
a2dp_capabilities->size, for_encoding))
 return key;
 }

 return NULL;
}

static uint8_t fill_capabilities(uint8_t 
capabilities_buffer[MAX_A2DP_CAPS_SIZE]) {
 a2dp_sbc_t *capabilities = (a2dp_sbc_t *) capabilities_buffer;

 pa_zero(*capabilities);

 capabilities->channel_mode = SBC_CHANNEL_MODE_MONO | 
SBC_CHANNEL_MODE_DUAL_CHANNEL | SBC_CHANNEL_MODE_STEREO |
  SBC_CHANNEL_MODE_JOINT_STEREO;
 capabilities->frequency = SBC_SAMPLING_FREQ_16000 | 
SBC_SAMPLING_FREQ_32000 | SBC_SAMPLING_FREQ_44100 |
   SBC_SAMPLING_FREQ_48000;
 capabilities->allocation_method = SBC_ALLOCATION_SNR | 
SBC_ALLOCATION_LOUDNESS;
 capabilities->subbands = SBC_SUBBANDS_4 | SBC_SUBBANDS_8;
 capabilities->block_length = SBC_BLOCK_LENGTH_4 | SBC_BLOCK_LENGTH_8 | 
SBC_BLOCK_LENGTH_12 | SBC_BLOCK_LENGTH_16;
 capabilities->min_bitpool = SBC_MIN_BITPOOL;
 capabilities->max_bitpool = SBC_BITPOOL_HQ_JOINT_STEREO_44100;

 return sizeof(*capabilities);
}

static bool is_configuration_valid(const uint8_t *config_buffer, uint8_t 
config_size) {
 const a2dp_sbc_t *config = (const a2dp_sbc_t *) config_buffer;

 if (config_size != sizeof(*config)) {
 pa_log_error("Invalid size of config buffer");
 return false;
 }

 if (config->frequency != SBC_SAMPLING_FREQ_16000 && config->frequency != 
SBC_SAMPLING_FREQ_32000 &&
 config->frequency != SBC_SAMPLING_FREQ_44100 && config->frequency != 
SBC_SAMPLING_FREQ_48000) {
 pa_log_error("Invalid sampling 

Re: [pulseaudio-discuss] no sound after rebooting

[Andrey Semashev]

On 6/20/19 3:40 PM, Adrian Mariano wrote:

Starting in Ubuntu 18.10, and continuing in 19.04, after I reboot my
computer I have no sound.  My sound device doesn't show up at all in
the mixer.  I just have a "dummy" device (that's what just happened)
or sometimes I get the wrong device (NVidia) showing up but the right
device (onboard Intel) missing.

Running "sudo alsa force-reload" fixes this issue, until the next reboot.

I filed this as a bug with Ubuntu

https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1828136

and somebody had me do various troubleshooting, but when he told me to
modify pulse-client.conf so that a log file would be created, I did
not get a log file.  At this point, he told me I should post here for
help with this issue.


See if you're affected by this bug:

https://bugs.launchpad.net/ubuntu/+source/timidity/+bug/1793640
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

[pulseaudio-discuss] Unable to change output device for The Talos Principle

[Andrey Semashev]

Hi,

I have multiple audio output devices, most importantly ASUS Xonar D2X, 
which is set as the default output device, and Builtin Audio. For some 
reason, when I start The Talos Principle, PA selects Builtin Audio as 
the output device for the game. If I Alt+Tab from it and try changing 
the device in pavucontrol to D2X, nothing happens, the game continues to 
use Builtin Audio for output. D2X works fine otherwise, and I can use it 
in other applications


I'm not sure if this is a game or PA issue. I've noticed PA select 
non-default devices for different applications, so I tend to think this 
is a PA problem. So, my questions are:


1. Is there a reason why PA would select a non-default device for an 
application?


2. I suspect, the answer to 1 is yes, if at some point another device 
was selected for the application and this was saved in some sort of 
cache. If so, where is that cache and how can I remove the application 
from it?


3. Is there a reason why PA would not allow me to select D2X for a 
particular application?


4. Is there a way to force the selection?

5. Is this a bug and if so, where should I report it?

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

Re: [pulseaudio-discuss] Problems with ASUS Xonar D2X & PulseAudio card detection.

[Andrey Semashev]

On 10/22/18 7:21 PM, Andrey Semashev wrote:

On 10/22/18 7:15 PM, Russell Treleaven wrote:


    Only I do want the 5.1 analog output.

Maybe your PCH card supports 5.1.


Maybe it does, but I really want the D2X card to output the 5.1 signal. 
The integrated audio is also used in my setup, also analog.


It used to work perfectly in Kubuntu 18.04 PulseAudio 11.1, so something 
was broken since then.


In case anyone else has this problem, I think I found the cause:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1799541/comments/20

In short, the timidity daemon grabbed ALSA PCM device before PulseAudio, 
which caused it not being able to open the D2X device. To solve the 
problem, disable or uninstall timidity and restart pulseaudio.

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

Re: [pulseaudio-discuss] Problems with ASUS Xonar D2X & PulseAudio card detection.

[Andrey Semashev]

On 10/22/18 7:15 PM, Russell Treleaven wrote:


Only I do want the 5.1 analog output.

Maybe your PCH card supports 5.1.


Maybe it does, but I really want the D2X card to output the 5.1 signal. 
The integrated audio is also used in my setup, also analog.


It used to work perfectly in Kubuntu 18.04 PulseAudio 11.1, so something 
was broken since then.

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

Re: [pulseaudio-discuss] Problems with ASUS Xonar D2X & PulseAudio card detection.

[Andrey Semashev]

On 10/22/18 6:51 PM, Russell Treleaven wrote:

Cool you have gained some insight.
I would define your sink as hw:D2X, as the card number can 
change but the name won't.


Ok. Just for the sake of testing, it also didn't add the sink to PA.


make a safety copy of ~/.asoundrc and make the file contain only this line.

defaults.namehint.extended on


Ok. I didn't have that file.


The please post the output of `aplay -L` and `amixer -cD2X contents`.


$ aplay -L
default
Playback/recording through the PulseAudio sound server
null
Discard all samples (playback) or generate zero samples (capture)
pulse
PulseAudio Sound Server
sysdefault:CARD=D2X
Xonar D2X, Multichannel
Default Audio Device
front:CARD=D2X,DEV=0
Xonar D2X, Multichannel
Front speakers
surround21:CARD=D2X,DEV=0
Xonar D2X, Multichannel
2.1 Surround output to Front and Subwoofer speakers
surround40:CARD=D2X,DEV=0
Xonar D2X, Multichannel
4.0 Surround output to Front and Rear speakers
surround41:CARD=D2X,DEV=0
Xonar D2X, Multichannel
4.1 Surround output to Front, Rear and Subwoofer speakers
surround50:CARD=D2X,DEV=0
Xonar D2X, Multichannel
5.0 Surround output to Front, Center and Rear speakers
surround51:CARD=D2X,DEV=0
Xonar D2X, Multichannel
5.1 Surround output to Front, Center, Rear and Subwoofer speakers
surround71:CARD=D2X,DEV=0
Xonar D2X, Multichannel
7.1 Surround output to Front, Center, Side, Rear and Woofer speakers
iec958:CARD=D2X,DEV=0
Xonar D2X, Multichannel
IEC958 (S/PDIF) Digital Audio Output
dmix:CARD=D2X,DEV=0
Xonar D2X, Multichannel
Direct sample mixing device
dmix:CARD=D2X,DEV=1
Xonar D2X, Digital
Direct sample mixing device
dsnoop:CARD=D2X,DEV=0
Xonar D2X, Multichannel
Direct sample snooping device
dsnoop:CARD=D2X,DEV=1
Xonar D2X, Digital
Direct sample snooping device
hw:CARD=D2X,DEV=0
Xonar D2X, Multichannel
Direct hardware device without any conversions
hw:CARD=D2X,DEV=1
Xonar D2X, Digital
Direct hardware device without any conversions
plughw:CARD=D2X,DEV=0
Xonar D2X, Multichannel
Hardware device with all software conversions
plughw:CARD=D2X,DEV=1
Xonar D2X, Digital
Hardware device with all software conversions
sysdefault:CARD=PCH
HDA Intel PCH, ALC892 Analog
Default Audio Device
front:CARD=PCH,DEV=0
HDA Intel PCH, ALC892 Analog
Front speakers
surround21:CARD=PCH,DEV=0
HDA Intel PCH, ALC892 Analog
2.1 Surround output to Front and Subwoofer speakers
surround40:CARD=PCH,DEV=0
HDA Intel PCH, ALC892 Analog
4.0 Surround output to Front and Rear speakers
surround41:CARD=PCH,DEV=0
HDA Intel PCH, ALC892 Analog
4.1 Surround output to Front, Rear and Subwoofer speakers
surround50:CARD=PCH,DEV=0
HDA Intel PCH, ALC892 Analog
5.0 Surround output to Front, Center and Rear speakers
surround51:CARD=PCH,DEV=0
HDA Intel PCH, ALC892 Analog
5.1 Surround output to Front, Center, Rear and Subwoofer speakers
surround71:CARD=PCH,DEV=0
HDA Intel PCH, ALC892 Analog
7.1 Surround output to Front, Center, Side, Rear and Woofer speakers
iec958:CARD=PCH,DEV=0
HDA Intel PCH, ALC892 Digital
IEC958 (S/PDIF) Digital Audio Output
hdmi:CARD=PCH,DEV=0
HDA Intel PCH, HDMI 0
HDMI Audio Output
dmix:CARD=PCH,DEV=0
HDA Intel PCH, ALC892 Analog
Direct sample mixing device
dmix:CARD=PCH,DEV=1
HDA Intel PCH, ALC892 Digital
Direct sample mixing device
dmix:CARD=PCH,DEV=3
HDA Intel PCH, HDMI 0
Direct sample mixing device
dsnoop:CARD=PCH,DEV=0
HDA Intel PCH, ALC892 Analog
Direct sample snooping device
dsnoop:CARD=PCH,DEV=1
HDA Intel PCH, ALC892 Digital
Direct sample snooping device
dsnoop:CARD=PCH,DEV=3
HDA Intel PCH, HDMI 0
Direct sample snooping device
hw:CARD=PCH,DEV=0
HDA Intel PCH, ALC892 Analog
Direct hardware device without any conversions
hw:CARD=PCH,DEV=1
HDA Intel PCH, ALC892 Digital
Direct hardware device without any conversions
hw:CARD=PCH,DEV=3
HDA Intel PCH, HDMI 0
Direct hardware device without any conversions
plughw:CARD=PCH,DEV=0
HDA Intel PCH, ALC892 Analog
Hardware device with all software conversions
plughw:CARD=PCH,DEV=1
HDA Intel PCH, ALC892 Digital
Hardware device with all software conversions
plughw:CARD=PCH,DEV=3
HDA Intel PCH, HDMI 0
Hardware device with all software conversions

$ amixer -cD2X contents
numid=2,iface=MIXER,name='Master Playback Switch'
  ; type=BOOLEAN,access=rw--,values=1
  : values=on
numid=1,iface=MIXER,name='Master Playback Volume'
  ; type=INTEGER,access=rw---R--,values=8,min=135,max=255,step=0
  : values=215,215,215,215,215,215,215,215
  | dBscale-min=-60.00dB,step=0.50dB,mute=0
numid=19,iface=MIXER,name='Line Capture Switch'
  ; type=BOOLEAN,access=rw--,values=1
  : values=off
numid=21,iface=MIXER,name='CD Capture Switch'
  ; type=BOOLEAN,access=rw--,values=1
  : values=off

Re: [pulseaudio-discuss] Problems with ASUS Xonar D2X & PulseAudio card detection.

[Andrey Semashev]

On 10/22/18 5:45 PM, Russell Treleaven wrote:

make a safety copy of /etc/pulse/default.pa 
edit the file to comment out the following lines like this

#load-module module-udev-detect
#load-module module-detect

add the following lines immediately following the ones you commented out

load-module module-alsa-sink device=hw:, 
sink_properties="your_sink"
load-module module-alsa-source device=hw:, 
source_properties="your_source"


You can discover the value for ,  and 
 via `aplay -l` and `arecord -l`


restart pulseaudio
`pulseaudio -k`

verify it worked
`pactl list sinks`
`pactl list sources`

Not a fix but it is a workaround


Thanks, but it doesn't really work for me. `aplay -l` shows:

card 0: D2X [Xonar D2X], device 0: Multichannel [Multichannel]
  Subdevices: 0/1
  Subdevice #0: subdevice #0
card 0: D2X [Xonar D2X], device 1: Digital [Digital]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: PCH [HDA Intel PCH], device 0: ALC892 Analog [ALC892 Analog]
  Subdevices: 0/1
  Subdevice #0: subdevice #0
card 1: PCH [HDA Intel PCH], device 1: ALC892 Digital [ALC892 Digital]
  Subdevices: 0/1
  Subdevice #0: subdevice #0
card 1: PCH [HDA Intel PCH], device 3: HDMI 0 [HDMI 0]
  Subdevices: 0/1
  Subdevice #0: subdevice #0

so the D2X (analog output) should be "hw:0,0", right? Adding this line:

load-module module-alsa-sink device=hw:0,0

does not add a D2X sink to `pactl list sinks`. Adding this line:

load-module module-alsa-sink device=hw:0,1

does add D2X *digital* ouptut sink. So PulseAudio has a specific problem 
with multichannel (5.1) analog output for some reason.

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

Re: [pulseaudio-discuss] Problems with ASUS Xonar D2X & PulseAudio card detection.

[Andrey Semashev]

On 10/1/18 4:20 PM, Hakan Bayındır wrote:

Hello All,

I'm using Debian Testing with KDE desktop, and having problem with
PulseAudio's sound card detection.

The system I'm using has three sound sinks (or cards if you wish):
- nVidia GTX680's sound output over DisplayPort.
- Intel's on board HD audio.
- ASUS Xonar D2X on PCIe (CMedia CM8788) [Preferred & default card].

All of the cards are well supported under Linux, ALSA and PulseAudio,
however PulseAudio is sometimes do not detecting my soundcard and revert
to one of the other cards as it pleases. The problem started with a
kernel update (I don't remember the exact version). What I've diagnosed
is as follows:
- Card is always operational. Present in lspci, initialized correctly
(D2X has hard relays as mute switches and I hear the distinctive CLACK
sound when the card is initialized).
- ALSA always detecting and calling the card settings from persistence
as it should, I verified with ALSA mixer.
- Deleting PulseAudio settings and restarting daemon generally has no help.
- When card is not detected it's completely absent from PulseAudio's
configuration and configuration database.
- I sometimes need to shutdown and restart the PC two to three times to
get the sound card back.
- It's more likely occur if I log-on to my PC late (press the power
button, get a cup of tea, drink some, wander off and login).
- There's no terse/warning/error logs anywhere. Everything is working as
it should on paper, so I cannot debug the problem.

Did anyone experience anything like this? I have the ability to debug
and patch the code if necessary, and if someone can at least show me the
right place for discussing this stuff I'd be grateful.


I'm having the same problem on Kubuntu 18.10, PulseAudio 12.2. `pactl 
list cards` does not list D2X but it is clearly present in `aplay -L` 
and `alsa-info` output.


Were you able to resolve or debug the problem?
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] PA 8.0 -- what happened to soxr- resamplers

[Andrey Semashev]

On Wednesday, 11 May 2016 11:11:19 MSK Matt Feifarek wrote:
> On Tue, May 10, 2016 at 11:47 PM, Luke Yelavich  > wrote:
> > 
> > We would have to get libsoxr into Ubuntu's main repository, which requires
> > commitment from Canonical to keep the package up to date, keep an eye on
> > bugs, etc. Given that pulse has to be built against libsoxr and must be
> > available at runtime, and given we already use speex and are happy with
> > the
> > default of speex-float-1, the extra effort of supporting another resampler
> > when its not our default is probably not worth it.
> 
> Ok, makes sense. But for me, it IS in Ubuntu (though universe, not main?):

I think, Canonical only supports main.

> I'm interested in quality more than speed, so speex-float-1 (as worst in
> the list) doesn't seem what I'm looking for. Does speex-float-10 compare
> favorably to the soxr methods?

Soxr resamplers typically provide better quality than speex, and are always 
faster.

http://lastique.github.io/src_test/

FWIW, I created a bug to enable soxr resamplers in the official Ubuntu 
packages. Feel 
free to add yourself as affected.

https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1574746

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

Re: [pulseaudio-discuss] PA 8.0 -- what happened to soxr- resamplers

[Andrey Semashev]

On Wednesday, 11 May 2016 11:02:41 MSK Luke Yelavich wrote:
> On Wed, May 11, 2016 at 02:36:57PM AEST, Arun Raghavan wrote:
> > On Wed, 11 May 2016, at 09:52 AM, Matt Feifarek wrote:
> > > I updated my Ubuntu box to 16.04, where I was running PA7, and now with
> > > PA8, I get:
> > > 
> > > W: [pulseaudio] resampler.c: Support for resampler 'soxr-vhq' not
> > > compiled
> > > in, reverting to 'auto'.
> > 
> > I'd look at the Ubuntu packaging about this. Upstream hasn't changed as
> > such in this regard.
> 
> We would have to get libsoxr into Ubuntu's main repository, which requires
> commitment from Canonical to keep the package up to date, keep an eye on
> bugs, etc. Given that pulse has to be built against libsoxr and must be
> available at runtime, and given we already use speex and are happy with the
> default of speex-float-1, the extra effort of supporting another resampler
> when its not our default is probably not worth it.

Some people are interested in quality and performance and soxr resamplers 
perform 
better in this regard. I had to build custom packages of PA when I found out 
that 
support for soxr has not been compiled in in the official packages.

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

Re: [pulseaudio-discuss] [PATCH v3] netbsd: Stop depending upon nonstandard __WORDSIZE

[Andrey Semashev]

On 2015-12-17 15:51, Andrey Semashev wrote:

On 2015-12-17 15:33, Pali Rohár wrote:

On Thursday 17 December 2015 15:10:12 Andrey Semashev wrote:

On 2015-12-17 14:50, Andrey Semashev wrote:

On 2015-12-17 02:44, Kamil Rytarowski wrote:


On 16.12.2015 11:02, Pali Rohár wrote:


Hi! There is probably no portable way for checking CPU type. But
you do not need to know CPU type here. You need to know if CPU has
fast 64bit numeric operations (and use 64bit speed optimization),
right?

And this could be possible by checking size of int_fast32_t type
(defined in stdint.h). If is same as size of int_fast64_t type then
you could use 64bit optimization otherwise not (= 32bit integers
are faster then 64bit).

But I will let this suggestion for reviewing of other people.


This sounds like a good way to go.


I don't think it does. int_fast32_t does not have to be 64-bit if
32-bit
integers are fast.


Yes. I did not wrote that int_fast32_t must be 64-bit. I wrote to
compare size of int_fast32_t and int_fast64_t.


And they will be different on x32 which, following your logic, means
that on x32 32-bit integers are faster than 64-bit. That's not true.


It _may_ be larger than 32-bit if 32-bit integers are
slow (most likely - do not have the target hardware support). I don't
think this is the case for x32 or x86_64.


On 64bi x86 sizeof(int_fast32_t) is 8 and sizeof(int_fast64_t) also 8. On
32bit x86 sizeof(int_fast32_t) is only 4.


On x86_64, yes:

gcc -m64 -dM -E - < /dev/null | grep FAST32
#define __INT_FAST32_MAX__ 0x7fffL
#define __INT_FAST32_TYPE__ long int
#define __UINT_FAST32_MAX__ 0xUL
#define __UINT_FAST32_TYPE__ long unsigned int

On x32, no:

gcc -mx32 -dM -E - < /dev/null | grep FAST32
#define __INT_FAST32_MAX__ 0x7fff
#define __INT_FAST32_TYPE__ int
#define __UINT_FAST32_MAX__ 0xU
#define __UINT_FAST32_TYPE__ unsigned int


If integer performance is what this preprocessor check influences, I'd
suggest checking the size of size_t. Or testing for particular
architectures explicitly, with 64-bit being the default and 32-bit only
for the tested architectures (this would probably make the code more
easily maintainable in the future).


I've sent this privately in error.

Also, it seems size_t is 32-bit on x32, so disregard that suggestion.


Important question is: what you want to distinguish? It is not 32 vs 64
bit processor right? It is if architecture has 64bit long registers? Or
something else?


The bitness of the architecture is a rather fuzzy term, but yes, it is
important to determine what for this check is needed. From the
discussion I gathered that the goal is to determine the largest fast
integer type for math.


Damn, I keep pressing Reply instead of Reply to all... Sorry again.

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

Re: [pulseaudio-discuss] [PATCH v3] netbsd: Stop depending upon nonstandard __WORDSIZE

[Andrey Semashev]

On 2015-12-17 14:50, Andrey Semashev wrote:

On 2015-12-17 02:44, Kamil Rytarowski wrote:


On 16.12.2015 11:02, Pali Rohár wrote:


Hi! There is probably no portable way for checking CPU type. But
you do not need to know CPU type here. You need to know if CPU has
fast 64bit numeric operations (and use 64bit speed optimization),
right?

And this could be possible by checking size of int_fast32_t type
(defined in stdint.h). If is same as size of int_fast64_t type then
you could use 64bit optimization otherwise not (= 32bit integers
are faster then 64bit).

But I will let this suggestion for reviewing of other people.


This sounds like a good way to go.


I don't think it does. int_fast32_t does not have to be 64-bit if 32-bit
integers are fast. It _may_ be larger than 32-bit if 32-bit integers are
slow (most likely - do not have the target hardware support). I don't
think this is the case for x32 or x86_64.

If integer performance is what this preprocessor check influences, I'd
suggest checking the size of size_t. Or testing for particular
architectures explicitly, with 64-bit being the default and 32-bit only
for the tested architectures (this would probably make the code more
easily maintainable in the future).


I've sent this privately in error.

Also, it seems size_t is 32-bit on x32, so disregard that suggestion.


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

Re: [pulseaudio-discuss] resampling speex-float

[Andrey Semashev]

On 2015-12-04 13:22, Alexander E. Patrakov wrote:

04.12.2015 15:28, Wenger Peter пишет:

I use ubuntu studio 14.04  and would like to set the resampling to a
higher level. So I edited /etc/pulse/daemon.con and set resample-methode
= speex-float-5. But it is not chanching. It stays on speex-floats-1.

Is there any idea, why it is not speex-float-5.



1. Your original mail is full of typos. Maybe there's a typo, too? E.g.
there is no "resample-methode", there is "resample-method".

2. Maybe there is a file, /home/youruser/.config/pulse/daemon.conf, that
PulseAudio parses first? If it exists, then PulseAudio does not even
look at /etc/pulse/daemon.conf


3. After editing the config file the daemon needs to be restarted.

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

Re: [pulseaudio-discuss] Crash in LFE filter if soxr resampler is used

[Andrey Semashev]

On Monday, November 02, 2015 08:43:55 AM David Henningsson wrote:
> On 2015-10-31 17:08, Andrey Semashev wrote:
> > Hi,
> > 
> > I've just upgraded to Kubuntu 15.10 and applied patches for libsoxr
> > resampler to PA 6.0 that comes with the distro. I'm seeing crashes in
> > the LFE filter if I use soxr-vhq resampler (I haven't tried the other
> > soxr* variants yet). Is this a known problem? Below is the backtrace
> > of one of the crashes.
> 
> Probably fixed by this commit:
> 
> commit 76e2cec9a2c3a09fc62ce62042d33375d9878471
> Author: Arun Raghavan <g...@arunraghavan.net>
> Date:   Thu Sep 17 09:44:49 2015 +0530
> 
>  lfe-filter: Deal with empty input chunks
> 
> 
> ...which is not (yet) in Ubuntu's backport of the lfe-filter patches.

Thanks. Yes, this patch seems to fix the problem.

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

Re: [pulseaudio-discuss] [PATCH] Use soxr_clear() if libsoxr version is 0.1.2 or later.

[Andrey Semashev]

On Monday, November 02, 2015 08:33:47 AM David Henningsson wrote:
> On 2015-10-31 16:59, Andrey Semashev wrote:
> > The 0.1.2 version of libsoxr fixes soxr_process() crash after soxr_clear()
> > is used, so check the library version at compile time and use
> > soxr_clear() if possible.
> Thanks for the patch, but if there is a bug in libsoxr that is fixed in
> 0.1.2 and above, wouldn't make more sense just to depend on libsoxr >=
> 0.1.2 in the configure script?
> 
> Is there a good reason for supporting older libsoxr versions?

Well, the code worked fine with 0.1.1 previously. There really is no major 
changes that require 0.1.2, I'm just removing the workaround that was 
previously needed.

Also that's the version that is shipped in the latest Ubuntu, for instance. I 
consider 0.1.1 wide spread, so it's good to allow people to compile the latest 
PA on the current systems.

If you don't want to keep support for 0.1.1 I can change the patch.

> > ---
> > 
> >   src/pulsecore/resampler/soxr.c | 15 ---
> >   1 file changed, 8 insertions(+), 7 deletions(-)
> > 
> > diff --git a/src/pulsecore/resampler/soxr.c
> > b/src/pulsecore/resampler/soxr.c index b5f0007..b1b2e19 100644
> > --- a/src/pulsecore/resampler/soxr.c
> > +++ b/src/pulsecore/resampler/soxr.c
> > @@ -64,17 +64,17 @@ static void resampler_soxr_free(pa_resampler *r) {
> > 
> >   }
> >   
> >   static void resampler_soxr_reset(pa_resampler *r) {
> > 
> > +#if SOXR_THIS_VERSION >= SOXR_VERSION(0, 1, 2)
> > +pa_assert(r);
> > +
> > +soxr_clear(r->impl.data);
> > +#else
> > +/* With libsoxr prior to 0.1.2 soxr_clear() makes soxr_process()
> > crash afterwards, + * so don't use this function and re-create the
> > context instead. */
>
> Also, you don't seem to have added code to re-create the context?

The code for re-creating the context is already there. That's how it worked 
unconditionally before the patch.

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

[pulseaudio-discuss] [PATCH] Use soxr_clear() if libsoxr version is 0.1.2 or later.

[Andrey Semashev]

The 0.1.2 version of libsoxr fixes soxr_process() crash after soxr_clear() is 
used, so check the library version at compile time and use soxr_clear() if 
possible.

---
 src/pulsecore/resampler/soxr.c | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/src/pulsecore/resampler/soxr.c b/src/pulsecore/resampler/soxr.c
index b5f0007..b1b2e19 100644
--- a/src/pulsecore/resampler/soxr.c
+++ b/src/pulsecore/resampler/soxr.c
@@ -64,17 +64,17 @@ static void resampler_soxr_free(pa_resampler *r) {
 }
 
 static void resampler_soxr_reset(pa_resampler *r) {
+#if SOXR_THIS_VERSION >= SOXR_VERSION(0, 1, 2)
+pa_assert(r);
+
+soxr_clear(r->impl.data);
+#else
+/* With libsoxr prior to 0.1.2 soxr_clear() makes soxr_process() crash 
afterwards,
+ * so don't use this function and re-create the context instead. */
 soxr_t old_state;
 
 pa_assert(r);
 
-/*
- * soxr_clear() makes soxr_process() crash afterwards,
- * so don't use this function until libsoxr is fixed.
- *
- * soxr_clear(r->impl.data);
- */
-
 old_state = r->impl.data;
 r->impl.data = NULL;
 
@@ -85,6 +85,7 @@ static void resampler_soxr_reset(pa_resampler *r) {
 r->impl.data = old_state;
 pa_log_error("Failed to reset libsoxr context");
 }
+#endif
 }
 
 static void resampler_soxr_update_rates(pa_resampler *r) {
-- 
2.5.0

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

[pulseaudio-discuss] Crash in LFE filter if soxr resampler is used

[Andrey Semashev]

Hi,

I've just upgraded to Kubuntu 15.10 and applied patches for libsoxr 
resampler to PA 6.0 that comes with the distro. I'm seeing crashes in 
the LFE filter if I use soxr-vhq resampler (I haven't tried the other 
soxr* variants yet). Is this a known problem? Below is the backtrace of 
one of the crashes.


Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7f92bf7fc700 (LWP 2769)]
0x7f92d2263267 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:55

55  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x7f92d2263267 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:55

#1  0x7f92d2264eca in __GI_abort () at abort.c:89
#2  0x7f92d37e8b8b in pa_xmalloc () from 
/usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-6.0.so
#3  0x7f92d37e8d79 in pa_xmemdup () from 
/usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-6.0.so
#4  0x7f92d3a60c65 in pa_lfe_filter_process (f=0x1ed1d60, 
buf=buf@entry=0x203ca50) at pulsecore/filter/lfe-filter.c:132
#5  0x7f92d3a7e923 in pa_resampler_run (r=0x203c8d0, 
in=0x7f92bf7f9490, out=0x7f92bf7f94b0) at pulsecore/resampler.c:1384
#6  0x7f92d3a896e3 in pa_sink_input_peek (i=i@entry=0x1ebe8d0, 
slength=22008, chunk=chunk@entry=0x7f92bf7f96d0, 
volume=volume@entry=0x7f92bf7f96e8) at pulsecore/sink-input.c:965
#7  0x7f92d3a91fa0 in fill_mix_info (s=s@entry=0x1e36350, 
length=length@entry=0x7f92bf7f9618, info=info@entry=0x7f92bf7f96d0, 
maxinfo=32) at pulsecore/sink.c:1016
#8  0x7f92d3a94d5d in pa_sink_render_into (s=s@entry=0x1e36350, 
target=target@entry=0x7f92bf7fbd20) at pulsecore/sink.c:1256
#9  0x7f92d3a952ff in pa_sink_render_into_full (s=0x1e36350, 
target=target@entry=0x7f92bf7fbde0) at pulsecore/sink.c:1340
#10 0x7f92cccf71ba in mmap_write (on_timeout=false, polled=false, 
sleep_usec=, u=0x1fc6f60) at modules/alsa/alsa-sink.c:645

#11 thread_func (userdata=0x1fc6f60) at modules/alsa/alsa-sink.c:1716
#12 0x7f92d38228b8 in ?? () from 
/usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-6.0.so
#13 0x7f92d2d136aa in start_thread (arg=0x7f92bf7fc700) at 
pthread_create.c:333
#14 0x7f92d2334eed in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:109


The crashes stop happening if I disable the filter in daemon.conf with 
"enable-lfe-remixing = no".


I realise 6.0+soxr is not an official configuration, but the patches are 
a rather straightforward backport of the code that is in master, so I 
suspect the same problem will be present in 7.x. If needed, I can 
provide the actual patch I'm using.

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

Re: [pulseaudio-discuss] [PATCH 0/4] Add support for libsoxr resampler

[Andrey Semashev]

On Wednesday 11 March 2015 20:48:11 you wrote:
 On Wed, 2015-03-11 at 20:27 +0200, Tanu Kaskinen wrote:
  
  I'm writing release notes for 7.0, and I'm wondering how to describe the
  three soxr resampler variants. Alexander says that all variants are
  perfect quality-wise (no audible distortions). Alexander also says that
  each variant takes about the same amount of CPU time, but Andrey says
  that there's 2x difference between mq and vhq. Who's right?
  
  To me it sounds like the hq and vhq variants are redundant, since mq is
  at least as fast (and on some hardware significantly faster) as the
  other variants, and there's no meaningful difference in quality.
 
 I now wrote something to the notes, feel free to comment if you'd like
 to change something:
 http://www.freedesktop.org/wiki/Software/PulseAudio/Notes/7.0/

Technically, up to 20 ms is not correct because sometimes the delay may be 
higher. I was careful about that when I updated the man pages.

Regarding hq vs vhq, I think I mentioned it somewhere, vhq does computation 
with more precision bits than hq, so it mostly targeted for high bit depth 
formats. Whether or not the difference is audible and under what conditions is 
an other question. I did some performance measurements, they are given on the 
page I referenced earlier [1].

[1] http://lastique.github.io/src_test/

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

Re: [pulseaudio-discuss] [PATCH v5 0/4] Add support for libsoxr resampler

[Andrey Semashev]

On Wednesday 14 January 2015 22:07:08 Peter Meerwald wrote:
  Andrey Semashev (4):
Added libsoxr resampler backend.
Enabled libsoxr resampler backend.
Added libsoxr detection and optional build of soxr resampler backend.
Added documentation for soxr resampling methods.
 
 thanks, pushed to -next

Thanks to you and all the reviewers. Do I understand correctly that the 'next' 
branch will be used for the next PA release, 7.0?

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

[pulseaudio-discuss] [PATCH 4/4] Added documentation for soxr resampling methods.

[Andrey Semashev]

---
 man/pulse-daemon.conf.5.xml.in | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/man/pulse-daemon.conf.5.xml.in b/man/pulse-daemon.conf.5.xml.in
index 754312e..d17131b 100644
--- a/man/pulse-daemon.conf.5.xml.in
+++ b/man/pulse-daemon.conf.5.xml.in
@@ -88,7 +88,8 @@ USA.
   optsrc-sinc-medium-quality/opt, optsrc-sinc-fastest/opt,
   optsrc-zero-order-hold/opt, optsrc-linear/opt,
   opttrivial/opt, optspeex-float-N/opt,
-  optspeex-fixed-N/opt, optffmpeg/opt. See the
+  optspeex-fixed-N/opt, optffmpeg/opt, optsoxr-mq/opt,
+  optsoxr-hq/opt, optsoxr-vhq/opt. See the
   documentation of libsamplerate and speex for explanations of the
   different src- and speex- methods, respectively. The method
   opttrivial/opt is the most basic algorithm implemented. If
@@ -98,8 +99,15 @@ USA.
   exist in two flavours: optfixed/opt and optfloat/opt. The former 
uses fixed point
   numbers, the latter relies on floating point numbers. On most
   desktop CPUs the float point resampler is a lot faster, and it
-  also offers slightly better quality. See the output of
-  optdump-resample-methods/opt for a complete list of all
+  also offers slightly better quality. The soxr-family methods
+  are based on libsoxr, a resampler library from the SoX sound processing 
utility.
+  The mq variant has the best performance of the three. The hq is more 
expensive
+  and, according to SoX developers, is considered the best choice for 
audio of up to 16 bits per sample.
+  The vhq variant has more precision than hq and is more suitable for 
larger samples. The Soxr resamplers
+  generally offer better quality at less CPU compared to other resamplers, 
such as speex.
+  The downside is that they can add a significant delay to the output
+  (usually up to around 20 ms, in rare cases more).
+  See the output of optdump-resample-methods/opt for a complete list 
of all
   available resamplers. Defaults to optspeex-float-1/opt. The
   opt--resample-method/opt command line option takes precedence.
   Note that some modules overwrite or allow overwriting of the
-- 
2.1.0

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

[pulseaudio-discuss] [PATCH v5 0/4] Add support for libsoxr resampler

[Andrey Semashev]

This is an updated set of patches first announced and discussed here:

v1 - http://comments.gmane.org/gmane.comp.audio.pulseaudio.general/22158
v2 - http://comments.gmane.org/gmane.comp.audio.pulseaudio.general/22239
v3 - http://comments.gmane.org/gmane.comp.audio.pulseaudio.general/22591
v4 - http://comments.gmane.org/gmane.comp.audio.pulseaudio.general/22625

Changes to v4:

* Disabled libsoxr backend for variable rate resampling.
* Updated license header in soxr.c (use FSF web URL instead of address).
* Removed unneeded return -1 statements in the unreachable places.
* Docs corrections.

Similar patches by Peter Meerwald:

http://lists.freedesktop.org/archives/pulseaudio-discuss/2014-August/021050.html

Andrey Semashev (4):
  Added libsoxr resampler backend.
  Enabled libsoxr resampler backend.
  Added libsoxr detection and optional build of soxr resampler backend.
  Added documentation for soxr resampling methods.

 configure.ac   |  17 +
 man/pulse-daemon.conf.5.xml.in |  14 +++-
 src/Makefile.am|   6 ++
 src/pulsecore/resampler.c  |  33 +++-
 src/pulsecore/resampler.h  |   4 +
 src/pulsecore/resampler/soxr.c | 167 +
 6 files changed, 234 insertions(+), 7 deletions(-)
 create mode 100644 src/pulsecore/resampler/soxr.c

-- 
2.1.0

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

[pulseaudio-discuss] [PATCH 1/4] Added libsoxr resampler backend.

[Andrey Semashev]

The new backend supports 3 quality levels: mq, hq and vhq; 16-bit integer and 
32-bit float samples. Discussion and quality assessment are here:

http://comments.gmane.org/gmane.comp.audio.pulseaudio.general/22158
---
 src/pulsecore/resampler/soxr.c | 167 +
 1 file changed, 167 insertions(+)
 create mode 100644 src/pulsecore/resampler/soxr.c

diff --git a/src/pulsecore/resampler/soxr.c b/src/pulsecore/resampler/soxr.c
new file mode 100644
index 000..b5f0007
--- /dev/null
+++ b/src/pulsecore/resampler/soxr.c
@@ -0,0 +1,167 @@
+/***
+  This file is part of PulseAudio.
+
+  Copyright 2014, 2015 Andrey Semashev
+
+  PulseAudio is free software; you can redistribute it and/or modify
+  it under the terms of the GNU Lesser General Public License as published
+  by the Free Software Foundation; either version 2.1 of the License,
+  or (at your option) any later version.
+
+  PulseAudio is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with PulseAudio; if not, see http://www.gnu.org/licenses/.
+***/
+
+#ifdef HAVE_CONFIG_H
+#include config.h
+#endif
+
+#include stddef.h
+#include soxr.h
+
+#include pulsecore/resampler.h
+
+static unsigned resampler_soxr_resample(pa_resampler *r, const pa_memchunk 
*input, unsigned in_n_frames,
+pa_memchunk *output, unsigned 
*out_n_frames) {
+soxr_t state;
+void *in, *out;
+size_t consumed = 0, produced = 0;
+
+pa_assert(r);
+pa_assert(input);
+pa_assert(output);
+pa_assert(out_n_frames);
+
+state = r-impl.data;
+pa_assert(state);
+
+in = pa_memblock_acquire_chunk(input);
+out = pa_memblock_acquire_chunk(output);
+
+pa_assert_se(soxr_process(state, in, in_n_frames, consumed, out, 
*out_n_frames, produced) == 0);
+
+pa_memblock_release(input-memblock);
+pa_memblock_release(output-memblock);
+
+*out_n_frames = produced;
+
+return in_n_frames - consumed;
+}
+
+static void resampler_soxr_free(pa_resampler *r) {
+pa_assert(r);
+
+if (!r-impl.data)
+return;
+
+soxr_delete(r-impl.data);
+r-impl.data = NULL;
+}
+
+static void resampler_soxr_reset(pa_resampler *r) {
+soxr_t old_state;
+
+pa_assert(r);
+
+/*
+ * soxr_clear() makes soxr_process() crash afterwards,
+ * so don't use this function until libsoxr is fixed.
+ *
+ * soxr_clear(r-impl.data);
+ */
+
+old_state = r-impl.data;
+r-impl.data = NULL;
+
+if (pa_resampler_soxr_init(r) == 0) {
+if (old_state)
+soxr_delete(old_state);
+} else {
+r-impl.data = old_state;
+pa_log_error(Failed to reset libsoxr context);
+}
+}
+
+static void resampler_soxr_update_rates(pa_resampler *r) {
+soxr_t old_state;
+
+pa_assert(r);
+
+/* There is no update method in libsoxr,
+ * so just re-create the resampler context */
+
+old_state = r-impl.data;
+r-impl.data = NULL;
+
+if (pa_resampler_soxr_init(r) == 0) {
+if (old_state)
+soxr_delete(old_state);
+} else {
+r-impl.data = old_state;
+pa_log_error(Failed to update libsoxr sample rates);
+}
+}
+
+int pa_resampler_soxr_init(pa_resampler *r) {
+soxr_t state;
+soxr_datatype_t io_format;
+soxr_io_spec_t io_spec;
+soxr_runtime_spec_t runtime_spec;
+unsigned long quality_recipe;
+soxr_quality_spec_t quality;
+soxr_error_t err = NULL;
+
+pa_assert(r);
+
+switch (r-work_format) {
+case PA_SAMPLE_S16NE:
+io_format = SOXR_INT16_I;
+break;
+case PA_SAMPLE_FLOAT32NE:
+io_format = SOXR_FLOAT32_I;
+break;
+default:
+pa_assert_not_reached();
+}
+
+io_spec = soxr_io_spec(io_format, io_format);
+
+/* Resample in one thread. Multithreading makes
+ * performance worse with small chunks of audio. */
+runtime_spec = soxr_runtime_spec(1);
+
+switch (r-method) {
+case PA_RESAMPLER_SOXR_MQ:
+quality_recipe = SOXR_MQ | SOXR_LINEAR_PHASE;
+break;
+case PA_RESAMPLER_SOXR_HQ:
+quality_recipe = SOXR_HQ | SOXR_LINEAR_PHASE;
+break;
+case PA_RESAMPLER_SOXR_VHQ:
+quality_recipe = SOXR_VHQ | SOXR_LINEAR_PHASE;
+break;
+default:
+pa_assert_not_reached();
+}
+
+quality = soxr_quality_spec(quality_recipe, 0);
+
+state = soxr_create(r-i_ss.rate, r-o_ss.rate, r-work_channels, err, 
io_spec, quality, runtime_spec);
+if (!state) {
+pa_log_error(Failed to create libsoxr resampler context: %s., (err ? 
err : [unknown error]));
+return -1;
+}
+
+r-impl.free

Re: [pulseaudio-discuss] [PATCH 2/4] Enabled libsoxr resampler backend.

[Andrey Semashev]

On Tuesday 13 January 2015 17:32:55 you wrote:
 Hello,
 
 On Mon, 12 Jan 2015, Andrey Semashev wrote:
 
 re-posting to list, hope that is OK
 
  On Monday 12 January 2015 17:36:19 you wrote:
Added ID and names for the resampler presets and also updated the
working
sample rate deduction to take the new resampler into account.
   
   what to do with PA_RESAMPLER_VARIABLE_RATE?
   
   resampler_soxr_update_rates() just recreates the context, I guess this
   will lead to crackling sound (not tested)
  
  Not crackling, but the quality will degrade.
 
 _update_rates() is used e.g. by module-rtp-recv to adjust the sample rate
 in tiny increments, i.e. while the stream is running, without stopping the
 stream
 
 there is a flag SOXR_VR which may provide variable-rate resampling, but
 this is currently not used; not sure if it would work, the code is called
 experimental

Interesting, I forgot about that flag. I'll take a look at it. What 
immediately bothers me is that one is supposed to supply a ratio between 
input/output rates as a double. This might be imprecise, although I'm not sure 
how precise other resamplers are wrt this feature.

   probably SOXR should be added to the clause in fix_method() which checks
   for PA_RESAMPLER_VARIABLE_RATE?
  
  Ok, but I see that by default it uses speex-float-1, which is
  significantly
  lower quality than any soxr mode. As I understand variable rate can be
  used by applications transparently for the user, and there is no way to
  influence this selection. Can I choose at least speex-float-5 as a
  fallback? Ideally, this should be a configurable option, though.
 
 I suggest do declare soxr to not support PA_RESAMPLER_VARIABLE_RATE in
 fix_method() for now and commit this work to -next (if there are no
 objections); fixups can be done later-on

I'm ok with that.

 one more comment; in
 int pa_resampler_soxr_init(pa_resampler *r) {
 ...
 default:
 pa_assert_not_reached();
 return -1;
 the return statement can be removed

Right, I thought pa_assert_not_reached() would be empty in Release build.

 looking at choose_auto_resampler(), I agree that this could be a bit
 smarter; e.g.
 * if our default resampler (resample-method= in daemon.conf) is
 speex-fixed- or speex-float- with a higher quality, we could probably set
 that instead of speex-float-1

Yes, and in case of soxr we could fallback to speex-float-5.

 * if the default resampler is speex-fixed-, probably we should not
 auto-switch to speex-float-

The speex-float- is converted to the corresponding speex-fixed-, if needed, 
further down in fix_method().

 but this can be done as a separate patch in the future


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

Re: [pulseaudio-discuss] [PATCH 4/4] Added documentation for soxr resampling methods.

[Andrey Semashev]

On Tuesday 13 January 2015 17:32:59 Peter Meerwald wrote:
 On Thu, 8 Jan 2015, Andrey Semashev wrote:
 
 extreme nitpicking below
 
  ---
  
   man/pulse-daemon.conf.5.xml.in | 14 +++---
   1 file changed, 11 insertions(+), 3 deletions(-)
  
  diff --git a/man/pulse-daemon.conf.5.xml.in
  b/man/pulse-daemon.conf.5.xml.in index 754312e..e1ee673 100644
  --- a/man/pulse-daemon.conf.5.xml.in
  +++ b/man/pulse-daemon.conf.5.xml.in
  @@ -88,7 +88,8 @@ USA.
  
 optsrc-sinc-medium-quality/opt, optsrc-sinc-fastest/opt,
 optsrc-zero-order-hold/opt, optsrc-linear/opt,
 opttrivial/opt, optspeex-float-N/opt,
  
  -  optspeex-fixed-N/opt, optffmpeg/opt. See the
  +  optspeex-fixed-N/opt, optffmpeg/opt, optsoxr-mq/opt,
  +  optsoxr-hq/opt, optsoxr-vhq/opt. See the
  
 documentation of libsamplerate and speex for explanations of the
 different src- and speex- methods, respectively. The method
 opttrivial/opt is the most basic algorithm implemented. If
  
  @@ -98,8 +99,15 @@ USA.
  
 exist in two flavours: optfixed/opt and optfloat/opt. The
 former uses fixed point numbers, the latter relies on floating
 point numbers. On most
 desktop CPUs the float point resampler is a lot faster, and it
  
  -  also offers slightly better quality. See the output of
  -  optdump-resample-methods/opt for a complete list of all
  +  also offers slightly better quality. The soxr- family methods
 
 Soxr-family
 
  +  are based on libsoxr, a resampler library from SoX sound processing
  utility.
 from the SoX
 
  +  The mq variant has the best performance of the three. The hq is
  more expensive +  and, according to SoX developers, is considered the
  best choice for audio of up to 16 bits per sample. +  The vhq variant
  has more precision than hq and is more suitable for larger samples. The
  Soxr resamplers +  generally offer better quality at less CPU
  compared to other resamplers, such as speex. +  The downside is that
  it can add a significant delay to the output
 they can add
 
  +  (usually, up to around 20 ms, in rare cases more).
 
 usually up to around 20 ms
 
  +  See the output of optdump-resample-methods/opt for a complete
  list of all 
 available resamplers. Defaults to optspeex-float-1/opt. The
 opt--resample-method/opt command line option takes precedence.
 Note that some modules overwrite or allow overwriting of the

Ok, thanks for your remarks.

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

Re: [pulseaudio-discuss] Merging soxr

[Andrey Semashev]

On Thursday 08 January 2015 11:29:42 Alexander E. Patrakov wrote:
 08.01.2015 01:52, Andrey Semashev wrote:
 
  Also, with PulseAudio forced to 44.1 kHz, FooBar2000 v1.2 (which uses
  DirectSound and thus, by default, resamples everything to 48 kHz) just
  plays silence (with a neverending stream of underruns in pulseaudio log)
  over soxr-vhq and works fine over speex-float-5. soxr-hq and soxr-mq
  also work fine with wine.
  
  I didn't quite understand this test, could you elaborate? Are you
  running Windows in a VM here? Which one?
 
 That's in wine. FooBar2000 v1.2 (and not any later version) is good for
 testing DirectSound-related code paths.

Hmm, I'm having trouble reproducing this (for now I'm trying with my patched 
PA 4.0 with soxr-vhq). In Foobar2000 1.2.9 on wine 1.6.2 I can only select 
Primary Sound Driver or Pulseaudio as the output, in both cases I cannot 
select the output format - it says that output format will be chosen 
automatically for the selected device. 'pactl list sink-inputs' says the 
signal sample rate is 44100 Hz. I tried to add resampler to 48 kHz in the 
Foobar2000 DSP pipeline, but the result is the same. In any case, the sound 
plays flawlessly.

Are there any specific settings I should do to reproduce the problem?

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

Re: [pulseaudio-discuss] Merging soxr

[Andrey Semashev]

On Thursday 08 January 2015 17:58:43 Alexander E. Patrakov wrote:
 08.01.2015 17:44, Andrey Semashev wrote:
  On Thursday 08 January 2015 11:29:42 Alexander E. Patrakov wrote:
  08.01.2015 01:52, Andrey Semashev wrote:
  Also, with PulseAudio forced to 44.1 kHz, FooBar2000 v1.2 (which uses
  DirectSound and thus, by default, resamples everything to 48 kHz) just
  plays silence (with a neverending stream of underruns in pulseaudio
  log)
  over soxr-vhq and works fine over speex-float-5. soxr-hq and soxr-mq
  also work fine with wine.
  
  I didn't quite understand this test, could you elaborate? Are you
  running Windows in a VM here? Which one?
  
  That's in wine. FooBar2000 v1.2 (and not any later version) is good for
  testing DirectSound-related code paths.
  
  Hmm, I'm having trouble reproducing this (for now I'm trying with my
  patched PA 4.0 with soxr-vhq). In Foobar2000 1.2.9 on wine 1.6.2 I can
  only select Primary Sound Driver or Pulseaudio as the output, in both
  cases I cannot select the output format - it says that output format will
  be chosen automatically for the selected device. 'pactl list sink-inputs'
  says the signal sample rate is 44100 Hz. I tried to add resampler to 48
  kHz in the Foobar2000 DSP pipeline, but the result is the same. In any
  case, the sound plays flawlessly.
  
  Are there any specific settings I should do to reproduce the problem?
 
 Well, I guess this is a left-over from my experimenting with the
 unpatched alsa output module. And your distribution applies the
 non-upstream pulseaudio output patch.
 
 So, please add this registry entry to reproduce the test result:
 
 [HKEY_CURRENT_USER\Software\Wine\Drivers]
 Audio=alsa
 
 regedit alsa.reg

No, that still doesn't help. After doing that and rebooting the sound still 
plays fine - I assume, directly through ALSA since 'pactl list sink-inputs' 
displays nothing. I don't see any devices that would route the signal back to 
PA.

 But it still boils down to a low-latency stream.

In that case, I think, there's nothing we can do. The resampler does have 
latency, and we have documented it. Just don't use it if you need a lower 
latency.

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

[pulseaudio-discuss] [PATCH 2/4] Enabled libsoxr resampler backend.

[Andrey Semashev]

Added ID and names for the resampler presets and also updated the working 
sample rate deduction to take the new resampler into account.
---
 src/pulsecore/resampler.c | 30 ++
 src/pulsecore/resampler.h |  4 
 2 files changed, 30 insertions(+), 4 deletions(-)

diff --git a/src/pulsecore/resampler.c b/src/pulsecore/resampler.c
index 183d05f..8a80b7d 100644
--- a/src/pulsecore/resampler.c
+++ b/src/pulsecore/resampler.c
@@ -111,6 +111,15 @@ static int (* const init_table[])(pa_resampler *r) = {
 [PA_RESAMPLER_AUTO]= NULL,
 [PA_RESAMPLER_COPY]= copy_init,
 [PA_RESAMPLER_PEAKS]   = pa_resampler_peaks_init,
+#ifdef HAVE_SOXR
+[PA_RESAMPLER_SOXR_MQ] = pa_resampler_soxr_init,
+[PA_RESAMPLER_SOXR_HQ] = pa_resampler_soxr_init,
+[PA_RESAMPLER_SOXR_VHQ]= pa_resampler_soxr_init,
+#else
+[PA_RESAMPLER_SOXR_MQ] = NULL,
+[PA_RESAMPLER_SOXR_HQ] = NULL,
+[PA_RESAMPLER_SOXR_VHQ]= NULL,
+#endif
 };
 
 static pa_resample_method_t choose_auto_resampler(pa_resample_flags_t flags) {
@@ -278,10 +287,20 @@ static pa_sample_format_t choose_work_format(
 }
 /* Else fall trough */
 case PA_RESAMPLER_PEAKS:
-if (a == PA_SAMPLE_S16NE || b == PA_SAMPLE_S16NE)
+/* PEAKS, COPY and TRIVIAL do not benefit from increased
+ * working precision, so for better performance use s16ne
+ * if either input or output fits in it. */
+if (a == PA_SAMPLE_S16NE || b == PA_SAMPLE_S16NE) {
 work_format = PA_SAMPLE_S16NE;
-else if (sample_format_more_precise(a, PA_SAMPLE_S16NE) ||
- sample_format_more_precise(b, PA_SAMPLE_S16NE))
+break;
+}
+/* Else fall trough */
+case PA_RESAMPLER_SOXR_MQ:
+case PA_RESAMPLER_SOXR_HQ:
+case PA_RESAMPLER_SOXR_VHQ:
+/* Do processing with max precision of input and output. */
+if (sample_format_more_precise(a, PA_SAMPLE_S16NE) ||
+sample_format_more_precise(b, PA_SAMPLE_S16NE))
 work_format = PA_SAMPLE_FLOAT32NE;
 else
 work_format = PA_SAMPLE_S16NE;
@@ -601,7 +620,10 @@ static const char * const resample_methods[] = {
 ffmpeg,
 auto,
 copy,
-peaks
+peaks,
+soxr-mq,
+soxr-hq,
+soxr-vhq
 };
 
 const char *pa_resample_method_to_string(pa_resample_method_t m) {
diff --git a/src/pulsecore/resampler.h b/src/pulsecore/resampler.h
index 5a84cf0..a0306e7 100644
--- a/src/pulsecore/resampler.h
+++ b/src/pulsecore/resampler.h
@@ -59,6 +59,9 @@ typedef enum pa_resample_method {
 PA_RESAMPLER_AUTO, /* automatic select based on sample format */
 PA_RESAMPLER_COPY,
 PA_RESAMPLER_PEAKS,
+PA_RESAMPLER_SOXR_MQ,
+PA_RESAMPLER_SOXR_HQ,
+PA_RESAMPLER_SOXR_VHQ,
 PA_RESAMPLER_MAX
 } pa_resample_method_t;
 
@@ -163,6 +166,7 @@ int pa_resampler_libsamplerate_init(pa_resampler *r);
 int pa_resampler_peaks_init(pa_resampler *r);
 int pa_resampler_speex_init(pa_resampler *r);
 int pa_resampler_trivial_init(pa_resampler*r);
+int pa_resampler_soxr_init(pa_resampler *r);
 
 /* Resampler-specific quirks */
 bool pa_speex_is_fixed_point(void);
-- 
2.1.0

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

[pulseaudio-discuss] [PATCH 3/4] Added libsoxr detection and optional build of soxr resampler backend.

[Andrey Semashev]

---
 configure.ac| 17 +
 src/Makefile.am |  6 ++
 2 files changed, 23 insertions(+)

diff --git a/configure.ac b/configure.ac
index 2ccf094..23144d1 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1140,6 +1140,21 @@ AS_IF([test x$with_speex = xyes  test 
x$HAVE_SPEEX = x0],
 AM_CONDITIONAL([HAVE_SPEEX], [test x$HAVE_SPEEX = x1])
 AS_IF([test x$HAVE_SPEEX = x1], AC_DEFINE([HAVE_SPEEX], 1, [Have speex]))
 
+ soxr (optional) 
+
+AC_ARG_WITH([soxr],
+AS_HELP_STRING([--without-soxr],[Omit soxr (resampling)]))
+
+AS_IF([test x$with_soxr != xno],
+[PKG_CHECK_MODULES(LIBSOXR, [ soxr = 0.1.1 ], HAVE_SOXR=1, HAVE_SOXR=0)],
+HAVE_SOXR=0)
+
+AS_IF([test x$with_soxr = xyes  test x$HAVE_SOXR = x0],
+[AC_MSG_ERROR([*** soxr support not found])])
+
+AM_CONDITIONAL([HAVE_SOXR], [test x$HAVE_SOXR = x1])
+AS_IF([test x$HAVE_SOXR = x1], AC_DEFINE([HAVE_SOXR], 1, [Have soxr]))
+
  Xen support (optional) 
 
 AC_ARG_ENABLE([xen],
@@ -1528,6 +1543,7 @@ AS_IF([test x$HAVE_FFTW = x1], ENABLE_FFTW=yes, 
ENABLE_FFTW=no)
 AS_IF([test x$HAVE_ORC = xyes], ENABLE_ORC=yes, ENABLE_ORC=no)
 AS_IF([test x$HAVE_ADRIAN_EC = x1], ENABLE_ADRIAN_EC=yes, 
ENABLE_ADRIAN_EC=no)
 AS_IF([test x$HAVE_SPEEX = x1], ENABLE_SPEEX=yes, ENABLE_SPEEX=no)
+AS_IF([test x$HAVE_SOXR = x1], ENABLE_SOXR=yes, ENABLE_SOXR=no)
 AS_IF([test x$HAVE_WEBRTC = x1], ENABLE_WEBRTC=yes, ENABLE_WEBRTC=no)
 AS_IF([test x$HAVE_TDB = x1], ENABLE_TDB=yes, ENABLE_TDB=no)
 AS_IF([test x$HAVE_GDBM = x1], ENABLE_GDBM=yes, ENABLE_GDBM=no)
@@ -1589,6 +1605,7 @@ echo 
 Enable orc:${ENABLE_ORC}
 Enable Adrian echo canceller:  ${ENABLE_ADRIAN_EC}
 Enable speex (resampler, AEC): ${ENABLE_SPEEX}
+Enable soxr (resampler):   ${ENABLE_SOXR}
 Enable WebRTC echo canceller:  ${ENABLE_WEBRTC}
 Enable gcov coverage:  ${ENABLE_GCOV}
 Enable unit tests: ${ENABLE_TESTS}
diff --git a/src/Makefile.am b/src/Makefile.am
index 88a824e..5a88531 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -1021,6 +1021,12 @@ libpulsecore_@PA_MAJORMINOR@_la_CFLAGS += 
$(LIBSPEEX_CFLAGS)
 libpulsecore_@PA_MAJORMINOR@_la_LIBADD += $(LIBSPEEX_LIBS)
 endif
 
+if HAVE_SOXR
+libpulsecore_@PA_MAJORMINOR@_la_SOURCES += pulsecore/resampler/soxr.c
+libpulsecore_@PA_MAJORMINOR@_la_CFLAGS += $(LIBSOXR_CFLAGS)
+libpulsecore_@PA_MAJORMINOR@_la_LIBADD += $(LIBSOXR_LIBS)
+endif
+
 if HAVE_LIBSAMPLERATE
 libpulsecore_@PA_MAJORMINOR@_la_SOURCES += pulsecore/resampler/libsamplerate.c
 libpulsecore_@PA_MAJORMINOR@_la_CFLAGS += $(LIBSAMPLERATE_CFLAGS)
-- 
2.1.0

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

[pulseaudio-discuss] [PATCH 1/4] Added libsoxr resampler backend.

[Andrey Semashev]

The new backend supports 3 quality levels: mq, hq and vhq; 16-bit integer and 
32-bit float samples. Discussion and quality assessment are here:

http://comments.gmane.org/gmane.comp.audio.pulseaudio.general/22158
---
 src/pulsecore/resampler/soxr.c | 171 +
 1 file changed, 171 insertions(+)
 create mode 100644 src/pulsecore/resampler/soxr.c

diff --git a/src/pulsecore/resampler/soxr.c b/src/pulsecore/resampler/soxr.c
new file mode 100644
index 000..769228b
--- /dev/null
+++ b/src/pulsecore/resampler/soxr.c
@@ -0,0 +1,171 @@
+/***
+  This file is part of PulseAudio.
+
+  Copyright 2014, 2015 Andrey Semashev
+
+  PulseAudio is free software; you can redistribute it and/or modify
+  it under the terms of the GNU Lesser General Public License as published
+  by the Free Software Foundation; either version 2.1 of the License,
+  or (at your option) any later version.
+
+  PulseAudio is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with PulseAudio; if not, write to the Free Software
+  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
+  USA.
+***/
+
+#ifdef HAVE_CONFIG_H
+#include config.h
+#endif
+
+#include stddef.h
+#include soxr.h
+
+#include pulsecore/resampler.h
+
+static unsigned resampler_soxr_resample(pa_resampler *r, const pa_memchunk 
*input, unsigned in_n_frames,
+pa_memchunk *output, unsigned 
*out_n_frames) {
+soxr_t state;
+void *in, *out;
+size_t consumed = 0, produced = 0;
+
+pa_assert(r);
+pa_assert(input);
+pa_assert(output);
+pa_assert(out_n_frames);
+
+state = r-impl.data;
+pa_assert(state);
+
+in = pa_memblock_acquire_chunk(input);
+out = pa_memblock_acquire_chunk(output);
+
+pa_assert_se(soxr_process(state, in, in_n_frames, consumed, out, 
*out_n_frames, produced) == 0);
+
+pa_memblock_release(input-memblock);
+pa_memblock_release(output-memblock);
+
+*out_n_frames = produced;
+
+return in_n_frames - consumed;
+}
+
+static void resampler_soxr_free(pa_resampler *r) {
+pa_assert(r);
+
+if (!r-impl.data)
+return;
+
+soxr_delete(r-impl.data);
+r-impl.data = NULL;
+}
+
+static void resampler_soxr_reset(pa_resampler *r) {
+soxr_t old_state;
+
+pa_assert(r);
+
+/*
+ * soxr_clear() makes soxr_process() crash afterwards,
+ * so don't use this function until libsoxr is fixed.
+ *
+ * soxr_clear(r-impl.data);
+ */
+
+old_state = r-impl.data;
+r-impl.data = NULL;
+
+if (pa_resampler_soxr_init(r) == 0) {
+if (old_state)
+soxr_delete(old_state);
+} else {
+r-impl.data = old_state;
+pa_log_error(Failed to reset libsoxr context);
+}
+}
+
+static void resampler_soxr_update_rates(pa_resampler *r) {
+soxr_t old_state;
+
+pa_assert(r);
+
+/* There is no update method in libsoxr,
+ * so just re-create the resampler context */
+
+old_state = r-impl.data;
+r-impl.data = NULL;
+
+if (pa_resampler_soxr_init(r) == 0) {
+if (old_state)
+soxr_delete(old_state);
+} else {
+r-impl.data = old_state;
+pa_log_error(Failed to update libsoxr sample rates);
+}
+}
+
+int pa_resampler_soxr_init(pa_resampler *r) {
+soxr_t state;
+soxr_datatype_t io_format;
+soxr_io_spec_t io_spec;
+soxr_runtime_spec_t runtime_spec;
+unsigned long quality_recipe;
+soxr_quality_spec_t quality;
+soxr_error_t err = NULL;
+
+pa_assert(r);
+
+switch (r-work_format) {
+case PA_SAMPLE_S16NE:
+io_format = SOXR_INT16_I;
+break;
+case PA_SAMPLE_FLOAT32NE:
+io_format = SOXR_FLOAT32_I;
+break;
+default:
+pa_assert_not_reached();
+return -1;
+}
+
+io_spec = soxr_io_spec(io_format, io_format);
+
+/* Resample in one thread. Multithreading makes
+ * performance worse with small chunks of audio. */
+runtime_spec = soxr_runtime_spec(1);
+
+switch (r-method) {
+case PA_RESAMPLER_SOXR_MQ:
+quality_recipe = SOXR_MQ | SOXR_LINEAR_PHASE;
+break;
+case PA_RESAMPLER_SOXR_HQ:
+quality_recipe = SOXR_HQ | SOXR_LINEAR_PHASE;
+break;
+case PA_RESAMPLER_SOXR_VHQ:
+quality_recipe = SOXR_VHQ | SOXR_LINEAR_PHASE;
+break;
+default:
+pa_assert_not_reached();
+return -1;
+}
+
+quality = soxr_quality_spec(quality_recipe, 0);
+
+state = soxr_create(r-i_ss.rate, r-o_ss.rate, r-work_channels, err, 
io_spec, quality, runtime_spec);
+if (!state) {
+pa_log_error(Failed to create

Re: [pulseaudio-discuss] [PATCH 2/4] Enabled libsoxr resampler backend.

[Andrey Semashev]

On Wed, Jan 7, 2015 at 7:39 PM, Peter Meerwald pme...@pmeerw.net wrote:
  
 case PA_RESAMPLER_PEAKS:
   -if (a == PA_SAMPLE_S16NE || b == PA_SAMPLE_S16NE)
   -work_format = PA_SAMPLE_S16NE;
 
  Were the rows above removed on purpose? I suppose the behaviour should
  be different between SOXR and PEAKS here.

 Yes, I did that intentionally. The point is that audio processing should be
 done with max precision of the input and output signals. I don't see why 
 PEAKS
 should be special in this regard - it does support both int16 and float
 samples.

 in any case, such change should be in a separate, independent patch

 peaks is a bit special as it just computes the maximum absolute sample
 magnitude over a number of samples; switching to float does not improve
 quality but causes (potentially expensive) floating point comparisions

 I think the current special case code for peaks, i.e.
 if (a == PA_SAMPLE_S16NE || b == PA_SAMPLE_S16NE)
work_format = PA_SAMPLE_S16NE;
 makes sense

Ok, I'll add this shortcut for PEAKS.
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

[pulseaudio-discuss] [PATCH 1/4] Added libsoxr resampler backend.

[Andrey Semashev]

The new backend supports 3 quality levels: mq, hq and vhq; 16-bit integer and 
32-bit float samples. Discussion and quality assessment are here:

http://comments.gmane.org/gmane.comp.audio.pulseaudio.general/22158
---
 src/pulsecore/resampler/soxr.c | 171 +
 1 file changed, 171 insertions(+)
 create mode 100644 src/pulsecore/resampler/soxr.c

diff --git a/src/pulsecore/resampler/soxr.c b/src/pulsecore/resampler/soxr.c
new file mode 100644
index 000..769228b
--- /dev/null
+++ b/src/pulsecore/resampler/soxr.c
@@ -0,0 +1,171 @@
+/***
+  This file is part of PulseAudio.
+
+  Copyright 2014, 2015 Andrey Semashev
+
+  PulseAudio is free software; you can redistribute it and/or modify
+  it under the terms of the GNU Lesser General Public License as published
+  by the Free Software Foundation; either version 2.1 of the License,
+  or (at your option) any later version.
+
+  PulseAudio is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with PulseAudio; if not, write to the Free Software
+  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
+  USA.
+***/
+
+#ifdef HAVE_CONFIG_H
+#include config.h
+#endif
+
+#include stddef.h
+#include soxr.h
+
+#include pulsecore/resampler.h
+
+static unsigned resampler_soxr_resample(pa_resampler *r, const pa_memchunk 
*input, unsigned in_n_frames,
+pa_memchunk *output, unsigned 
*out_n_frames) {
+soxr_t state;
+void *in, *out;
+size_t consumed = 0, produced = 0;
+
+pa_assert(r);
+pa_assert(input);
+pa_assert(output);
+pa_assert(out_n_frames);
+
+state = r-impl.data;
+pa_assert(state);
+
+in = pa_memblock_acquire_chunk(input);
+out = pa_memblock_acquire_chunk(output);
+
+pa_assert_se(soxr_process(state, in, in_n_frames, consumed, out, 
*out_n_frames, produced) == 0);
+
+pa_memblock_release(input-memblock);
+pa_memblock_release(output-memblock);
+
+*out_n_frames = produced;
+
+return in_n_frames - consumed;
+}
+
+static void resampler_soxr_free(pa_resampler *r) {
+pa_assert(r);
+
+if (!r-impl.data)
+return;
+
+soxr_delete(r-impl.data);
+r-impl.data = NULL;
+}
+
+static void resampler_soxr_reset(pa_resampler *r) {
+soxr_t old_state;
+
+pa_assert(r);
+
+/*
+ * soxr_clear() makes soxr_process() crash afterwards,
+ * so don't use this function until libsoxr is fixed.
+ *
+ * soxr_clear(r-impl.data);
+ */
+
+old_state = r-impl.data;
+r-impl.data = NULL;
+
+if (pa_resampler_soxr_init(r) == 0) {
+if (old_state)
+soxr_delete(old_state);
+} else {
+r-impl.data = old_state;
+pa_log_error(Failed to reset libsoxr context);
+}
+}
+
+static void resampler_soxr_update_rates(pa_resampler *r) {
+soxr_t old_state;
+
+pa_assert(r);
+
+/* There is no update method in libsoxr,
+ * so just re-create the resampler context */
+
+old_state = r-impl.data;
+r-impl.data = NULL;
+
+if (pa_resampler_soxr_init(r) == 0) {
+if (old_state)
+soxr_delete(old_state);
+} else {
+r-impl.data = old_state;
+pa_log_error(Failed to update libsoxr sample rates);
+}
+}
+
+int pa_resampler_soxr_init(pa_resampler *r) {
+soxr_t state;
+soxr_datatype_t io_format;
+soxr_io_spec_t io_spec;
+soxr_runtime_spec_t runtime_spec;
+unsigned long quality_recipe;
+soxr_quality_spec_t quality;
+soxr_error_t err = NULL;
+
+pa_assert(r);
+
+switch (r-work_format) {
+case PA_SAMPLE_S16NE:
+io_format = SOXR_INT16_I;
+break;
+case PA_SAMPLE_FLOAT32NE:
+io_format = SOXR_FLOAT32_I;
+break;
+default:
+pa_assert_not_reached();
+return -1;
+}
+
+io_spec = soxr_io_spec(io_format, io_format);
+
+/* Resample in one thread. Multithreading makes
+ * performance worse with small chunks of audio. */
+runtime_spec = soxr_runtime_spec(1);
+
+switch (r-method) {
+case PA_RESAMPLER_SOXR_MQ:
+quality_recipe = SOXR_MQ | SOXR_LINEAR_PHASE;
+break;
+case PA_RESAMPLER_SOXR_HQ:
+quality_recipe = SOXR_HQ | SOXR_LINEAR_PHASE;
+break;
+case PA_RESAMPLER_SOXR_VHQ:
+quality_recipe = SOXR_VHQ | SOXR_LINEAR_PHASE;
+break;
+default:
+pa_assert_not_reached();
+return -1;
+}
+
+quality = soxr_quality_spec(quality_recipe, 0);
+
+state = soxr_create(r-i_ss.rate, r-o_ss.rate, r-work_channels, err, 
io_spec, quality, runtime_spec);
+if (!state) {
+pa_log_error(Failed to create

[pulseaudio-discuss] [PATCH 4/4] Added documentation for soxr resampling methods.

[Andrey Semashev]

---
 man/pulse-daemon.conf.5.xml.in | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/man/pulse-daemon.conf.5.xml.in b/man/pulse-daemon.conf.5.xml.in
index 754312e..e1ee673 100644
--- a/man/pulse-daemon.conf.5.xml.in
+++ b/man/pulse-daemon.conf.5.xml.in
@@ -88,7 +88,8 @@ USA.
   optsrc-sinc-medium-quality/opt, optsrc-sinc-fastest/opt,
   optsrc-zero-order-hold/opt, optsrc-linear/opt,
   opttrivial/opt, optspeex-float-N/opt,
-  optspeex-fixed-N/opt, optffmpeg/opt. See the
+  optspeex-fixed-N/opt, optffmpeg/opt, optsoxr-mq/opt,
+  optsoxr-hq/opt, optsoxr-vhq/opt. See the
   documentation of libsamplerate and speex for explanations of the
   different src- and speex- methods, respectively. The method
   opttrivial/opt is the most basic algorithm implemented. If
@@ -98,8 +99,15 @@ USA.
   exist in two flavours: optfixed/opt and optfloat/opt. The former 
uses fixed point
   numbers, the latter relies on floating point numbers. On most
   desktop CPUs the float point resampler is a lot faster, and it
-  also offers slightly better quality. See the output of
-  optdump-resample-methods/opt for a complete list of all
+  also offers slightly better quality. The soxr- family methods
+  are based on libsoxr, a resampler library from SoX sound processing 
utility.
+  The mq variant has the best performance of the three. The hq is more 
expensive
+  and, according to SoX developers, is considered the best choice for 
audio of up to 16 bits per sample.
+  The vhq variant has more precision than hq and is more suitable for 
larger samples. The Soxr resamplers
+  generally offer better quality at less CPU compared to other resamplers, 
such as speex.
+  The downside is that it can add a significant delay to the output
+  (usually, up to around 20 ms, in rare cases more).
+  See the output of optdump-resample-methods/opt for a complete list 
of all
   available resamplers. Defaults to optspeex-float-1/opt. The
   opt--resample-method/opt command line option takes precedence.
   Note that some modules overwrite or allow overwriting of the
-- 
2.1.0

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

[pulseaudio-discuss] [PATCH 3/4] Added libsoxr detection and optional build of soxr resampler backend.

[Andrey Semashev]

---
 configure.ac| 17 +
 src/Makefile.am |  6 ++
 2 files changed, 23 insertions(+)

diff --git a/configure.ac b/configure.ac
index 2ccf094..23144d1 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1140,6 +1140,21 @@ AS_IF([test x$with_speex = xyes  test 
x$HAVE_SPEEX = x0],
 AM_CONDITIONAL([HAVE_SPEEX], [test x$HAVE_SPEEX = x1])
 AS_IF([test x$HAVE_SPEEX = x1], AC_DEFINE([HAVE_SPEEX], 1, [Have speex]))
 
+ soxr (optional) 
+
+AC_ARG_WITH([soxr],
+AS_HELP_STRING([--without-soxr],[Omit soxr (resampling)]))
+
+AS_IF([test x$with_soxr != xno],
+[PKG_CHECK_MODULES(LIBSOXR, [ soxr = 0.1.1 ], HAVE_SOXR=1, HAVE_SOXR=0)],
+HAVE_SOXR=0)
+
+AS_IF([test x$with_soxr = xyes  test x$HAVE_SOXR = x0],
+[AC_MSG_ERROR([*** soxr support not found])])
+
+AM_CONDITIONAL([HAVE_SOXR], [test x$HAVE_SOXR = x1])
+AS_IF([test x$HAVE_SOXR = x1], AC_DEFINE([HAVE_SOXR], 1, [Have soxr]))
+
  Xen support (optional) 
 
 AC_ARG_ENABLE([xen],
@@ -1528,6 +1543,7 @@ AS_IF([test x$HAVE_FFTW = x1], ENABLE_FFTW=yes, 
ENABLE_FFTW=no)
 AS_IF([test x$HAVE_ORC = xyes], ENABLE_ORC=yes, ENABLE_ORC=no)
 AS_IF([test x$HAVE_ADRIAN_EC = x1], ENABLE_ADRIAN_EC=yes, 
ENABLE_ADRIAN_EC=no)
 AS_IF([test x$HAVE_SPEEX = x1], ENABLE_SPEEX=yes, ENABLE_SPEEX=no)
+AS_IF([test x$HAVE_SOXR = x1], ENABLE_SOXR=yes, ENABLE_SOXR=no)
 AS_IF([test x$HAVE_WEBRTC = x1], ENABLE_WEBRTC=yes, ENABLE_WEBRTC=no)
 AS_IF([test x$HAVE_TDB = x1], ENABLE_TDB=yes, ENABLE_TDB=no)
 AS_IF([test x$HAVE_GDBM = x1], ENABLE_GDBM=yes, ENABLE_GDBM=no)
@@ -1589,6 +1605,7 @@ echo 
 Enable orc:${ENABLE_ORC}
 Enable Adrian echo canceller:  ${ENABLE_ADRIAN_EC}
 Enable speex (resampler, AEC): ${ENABLE_SPEEX}
+Enable soxr (resampler):   ${ENABLE_SOXR}
 Enable WebRTC echo canceller:  ${ENABLE_WEBRTC}
 Enable gcov coverage:  ${ENABLE_GCOV}
 Enable unit tests: ${ENABLE_TESTS}
diff --git a/src/Makefile.am b/src/Makefile.am
index 88a824e..5a88531 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -1021,6 +1021,12 @@ libpulsecore_@PA_MAJORMINOR@_la_CFLAGS += 
$(LIBSPEEX_CFLAGS)
 libpulsecore_@PA_MAJORMINOR@_la_LIBADD += $(LIBSPEEX_LIBS)
 endif
 
+if HAVE_SOXR
+libpulsecore_@PA_MAJORMINOR@_la_SOURCES += pulsecore/resampler/soxr.c
+libpulsecore_@PA_MAJORMINOR@_la_CFLAGS += $(LIBSOXR_CFLAGS)
+libpulsecore_@PA_MAJORMINOR@_la_LIBADD += $(LIBSOXR_LIBS)
+endif
+
 if HAVE_LIBSAMPLERATE
 libpulsecore_@PA_MAJORMINOR@_la_SOURCES += pulsecore/resampler/libsamplerate.c
 libpulsecore_@PA_MAJORMINOR@_la_CFLAGS += $(LIBSAMPLERATE_CFLAGS)
-- 
2.1.0

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

Re: [pulseaudio-discuss] Merging soxr

[Andrey Semashev]

On Wednesday 19 November 2014 00:58:04 Alexander E. Patrakov wrote:
 19.11.2014 00:42, Andrey Semashev wrote:
  On Tuesday 18 November 2014 21:32:53 Alexander E. Patrakov wrote:
  18.11.2014 19:14, David Henningsson wrote:
  On 2014-11-18 14:46, Alexander E. Patrakov wrote:
  Add support for libsoxr resampler: David's objection about overriding
  pa_resampler_request is 100% valid, and the patchset cannot be merged
  without taking it into account.
  
  Well, the result will be inoptimal rather than completely not working
  without a working pa_resampler_request (especially given that Andrey
  seems to be satisfied with the current behaviour). If we're given fewer
  samples back than we expected, we'll just go through another round of
  resampling/mixing/etc, which I assume is what happens here.
  
  Well, now I have looked at the code in sink.c and sink-input.c, and I
  must say that I don't like it. Namely, there are assertions in
  
  fill_mix_info():
pa_assert(info-chunk.memblock);
pa_assert(info-chunk.length  0);
  
  At the very least, the first assertion should be moved up, because just
  above them, in the conditional statement, info-chunk.memblock is passed
  to pa_memblock_is_silence().
  
  Also there are assertions in pa_sink_input_peek() that are very similar
  in nature, and I don't see how it is guaranteed that the assertions
  never fail.
  
  So the devious sequence of events seems to be (assuming S16 stereo
  samples):
  
  pa_sink_input_peek is called with slength == 8 or something like that.
  
  pa_resampler_request() returns 8 or something like that.
  
  i-pop(), when asked to provide 8 bytes, creates a memchunk (tchunk) of
  this length.
  
  pa_resampler_run() eats the full tchunk, but produces nothing (an empty
  rchunk).
  
  As rchunk is empty, nothing gets pushed onto render_memblockq.
  
  Then pa_memblockq_peek() gets called, and it is asserted that the
  returned chunk exists and is not empty. Which looks dubious, and I think
  that we can try triggering this with a very-low-latency client
  (unpatched wine or maybe qemu?).
  
  So, incorrect results from pa_resampler_request() look dangerous when
  the difference results in zero vs non-zero output samples from
  pa_resampler_run().
  
  Of course, all of the above is in no way specific to the soxr resampler.
  An imprecise pa_resampler_request() is a bug. What bothers me is that
  soxr has a higher chance to trigger this bug.
  
  So, what will be the resolution of this problem? Should I work towards
  relaxing the requirement on pa_resampler_request() being precise or is
  this
  requirement permanent?
 
 I think that the temporary resolution would be to add a loop that calls
 pa_resampler_run repeatedly. IOW, the loop that David assumed as
 existing but which actually doesn't exist in pa_sink_input_peek().

I finally got some time to dive into the code, sorry for the delay.

As far as I understand the code, the loop is already there in 
pa_sink_input_peek() (see sink-input.c:924, while (tchunk.length  0)). The 
outer loop (sink-input.c:893, while (!pa_memblockq_is_readable(i-
thread_info.render_memblockq))) will end when either render_memblockq is not 
empty or the sink input is drained; in the latter case render_memblockq can be 
empty.

However, render_memblockq is initialized with a silence chunk in 
pa_sink_input_new(), which means that when the queue is empty it should return 
silence. This means that pa_memblockq_peek() in sink-input.c:993 and the 
following asserts should never fail. Same for the asserts in fill_mix_info(), 
the loop should be cut short by pa_memblock_is_silence(). pa_assert(info-
chunk.memblock); could be moved upper though, but it it doesn't matter for 
the case in point.

Am I missing something?

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

Re: [pulseaudio-discuss] Merging soxr

[Andrey Semashev]

On Tue, Jan 6, 2015 at 10:55 PM, Alexander E. Patrakov
patra...@gmail.com wrote:
 06.01.2015 19:17, Andrey Semashev wrote:

 As far as I understand the code, the loop is already there in
 pa_sink_input_peek() (see sink-input.c:924, while (tchunk.length  0)).
 The
 outer loop (sink-input.c:893, while (!pa_memblockq_is_readable(i-

 thread_info.render_memblockq))) will end when either render_memblockq is
 not

 empty or the sink input is drained; in the latter case render_memblockq
 can be
 empty.

 The while (tchunk.length  0) loop calls the resampler until it eats all
 of the available samples in tchunk. This looks insufficient, because the
 testcase quoted above relies on the condition that the resampler eats all of
 the available samples in tchunk (thus ending the loop), but produces
 nothing.

 However, render_memblockq is initialized with a silence chunk in
 pa_sink_input_new(), which means that when the queue is empty it should
 return
 silence. This means that pa_memblockq_peek() in sink-input.c:993 and the
 following asserts should never fail. Same for the asserts in
 fill_mix_info(),
 the loop should be cut short by pa_memblock_is_silence(). pa_assert(info-

 chunk.memblock); could be moved upper though, but it it doesn't matter
 for

 the case in point.

 So, instead of an assertion failure that I predicted, we get a chunk of
 silence regularly inserted into the middle of the low-latency stream being
 resampled. Still bad. Thanks for correcting my logic, though.

Yes, but it's not regularly as you say. In practice I've never heard
anything like that (it would sound like audio cracking or something
like that). I assume, soxr does produce audio for any practical amount
of input samples (or there are other PA-specific factors in play). The
silence would be generated while the resampler is filling, and during
this period silence is exactly what is needed.

If no further modifications are needed to the surrounding code, are my
patches sufficient or do I have to rebase or modify them?
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Merging soxr (was: Re: Patch review status wiki page updated)

[Andrey Semashev]

On Tue, Nov 18, 2014 at 5:14 PM, David Henningsson
david.hennings...@canonical.com wrote:


 On 2014-11-18 14:46, Alexander E. Patrakov wrote:

 Add support for libsoxr resampler: David's objection about overriding
 pa_resampler_request is 100% valid, and the patchset cannot be merged
 without taking it into account.


 Well, the result will be inoptimal rather than completely not working
 without a working pa_resampler_request (especially given that Andrey seems
 to be satisfied with the current behaviour). If we're given fewer samples
 back than we expected, we'll just go through another round of
 resampling/mixing/etc, which I assume is what happens here.

 We could also statically add 20 ms to pa_resampler_request (only in case
 soxr is selected, of course) and see if that gives a better result from an
 optimality perspective.

 So, it looks like we are waiting for a
 new version - not only of the patchset, but also of libsoxr. Otherwise
 there is no API to implement pa_resampler_request.

I'm not sure how pa_resampler_request is used in PA. If it's just an
estimate (e.g. to allocate buffers), and the code that uses the
resampler actually uses the sample counts consumed and produced by the
resampler, everything should work fine. Is there a context where the
resampler absolutely must produce samples according to
pa_resampler_request?
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Merging soxr

[Andrey Semashev]

On Tuesday 18 November 2014 21:32:53 Alexander E. Patrakov wrote:
 18.11.2014 19:14, David Henningsson wrote:
  On 2014-11-18 14:46, Alexander E. Patrakov wrote:
  Add support for libsoxr resampler: David's objection about overriding
  pa_resampler_request is 100% valid, and the patchset cannot be merged
  without taking it into account.
  
  Well, the result will be inoptimal rather than completely not working
  without a working pa_resampler_request (especially given that Andrey
  seems to be satisfied with the current behaviour). If we're given fewer
  samples back than we expected, we'll just go through another round of
  resampling/mixing/etc, which I assume is what happens here.
 
 Well, now I have looked at the code in sink.c and sink-input.c, and I
 must say that I don't like it. Namely, there are assertions in
 fill_mix_info():
 
  pa_assert(info-chunk.memblock);
  pa_assert(info-chunk.length  0);
 
 At the very least, the first assertion should be moved up, because just
 above them, in the conditional statement, info-chunk.memblock is passed
 to pa_memblock_is_silence().
 
 Also there are assertions in pa_sink_input_peek() that are very similar
 in nature, and I don't see how it is guaranteed that the assertions
 never fail.
 
 So the devious sequence of events seems to be (assuming S16 stereo samples):
 
 pa_sink_input_peek is called with slength == 8 or something like that.
 
 pa_resampler_request() returns 8 or something like that.
 
 i-pop(), when asked to provide 8 bytes, creates a memchunk (tchunk) of
 this length.
 
 pa_resampler_run() eats the full tchunk, but produces nothing (an empty
 rchunk).
 
 As rchunk is empty, nothing gets pushed onto render_memblockq.
 
 Then pa_memblockq_peek() gets called, and it is asserted that the
 returned chunk exists and is not empty. Which looks dubious, and I think
 that we can try triggering this with a very-low-latency client
 (unpatched wine or maybe qemu?).
 
 So, incorrect results from pa_resampler_request() look dangerous when
 the difference results in zero vs non-zero output samples from
 pa_resampler_run().
 
 Of course, all of the above is in no way specific to the soxr resampler.
 An imprecise pa_resampler_request() is a bug. What bothers me is that
 soxr has a higher chance to trigger this bug.

So, what will be the resolution of this problem? Should I work towards 
relaxing the requirement on pa_resampler_request() being precise or is this 
requirement permanent?

Out of my experience, you generally can't make a function like 
pa_resampler_request() to be always correct. Speex is rather special in the 
way it generates silence while filling, and it has constant delay. I could 
probably emulate such behavior for soxr by adding a repacketizer before the 
resampler and then adding silence samples before the first output sample is 
produced. pa_resampler_request() for soxr then could return something like 40 
ms, just to be sure you'll get some samples with this amount of input. Would 
this be an acceptable solution?

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

Re: [pulseaudio-discuss] [PATCH 0/4] Add support for libsoxr resampler

[Andrey Semashev]

On Monday 17 November 2014 15:09:14 David Henningsson wrote:
 
 Thanks for the tests. I think I misunderstood delay: I thought of delay
 as having 20 ms of zero samples in the beginning, but instead soxr will
 refuse to give you any samples out until you have fed it with 20 ms of
 samples in. Correct?

Yes, that's right. Speex also has the same behavior, if you call 
speex_resampler_skip_zeros() on the context. AFAIR, ffmpeg also works the same 
way.

 So then the variable delay would not result in artifacts, it will just
 be difficult to predict how many samples you'll get from the resampler.
 
 I'm wondering if we then need to override pa_resampler_request to do
 something different for soxr? Is there a way you can ask soxr to do the
 equivalent of pa_resampler_request, i e, give you an answer to how many
 samples do I need to input if I want x samples of output?

Hmm, I don't think there is. I mentioned soxr_delay() earlier, but it works 
post-factum (i.e. returns the current delay). I didn't see any other delay-
related API.

You could probably implement a repacketizer in the resampler to guarantee that 
the frame size is constant, and then use soxr_delay() as the approximation, 
but even then it probably wouldn't work for a few frames in the beginning, 
while the resampler is filling.

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

Re: [pulseaudio-discuss] [PATCH 0/4] Add support for libsoxr resampler

[Andrey Semashev]

On Friday 14 November 2014 11:37:07 you wrote:
 On Friday 14 November 2014 08:26:18 David Henningsson wrote:
  On 2014-11-13 23:49, Andrey Semashev wrote:
   I do not have an explanation for such diverse range of the delay value,
   and
   its dependency on the frame size. It doesn't look like the filter is
   learning from the input in some way since the delay doesn't depend on
   the
   content. Perhaps there is some extensive buffering in the
   implementation.
  
  Well, the delay must be constant given the parameters. If the delay was
  varying during playback, that would probably cause very interesting
  sound effects, such as music being slightly out of tempo or so...
 
 I've been using soxr-vhq with PA 4.0 on my working machine for about a month
 now, and never heard any sound artefacts.

I ran the test with printing the delay on each audio chunk. With constant 
frame size the delay remains pretty much constant. In a ~3.5 minute 44.1 kHz 
input content fed in 20 ms frames there was one (65-th, 1300 ms from the 
start) output chunk of 953 samples (instead of the usual 960), which increased 
the delay from 20.000 ms to 20.146 ms. It stayed constant until the very end, 
when the resampler was flushed. The target sample rate was 48 kHz.

  What does vary during playback, however, is how big chunks we pass into
  the resampler in every go. Which begs the question if it is the first
  chunk that determines the delay, or...?
 
 So PA uses variable frame size? I can try to modify the test for that. Are
 there any reasonable limits of the frame size?

With variable frame size (I tried random values between 20 and 100 ms) the 
delay also varies a lot and can be anywhere between 3 and 20 ms. The resampler 
fills or flushes its buffers as it sees fit, in response to the input frame 
size changes. There doesn't seem to be any particular pattern on the delay 
variation (i.e. it looks as random as the input frame size is).

The resulting audio did not have any artefacts or audible quality degradation. 
I believe, this is expected in a real-time application as well, since you 
would expect the audio data rate to be more or less constant, even if 
packetized in randomly sized frames. At the output of the resampler you would 
get frames as randomly sized as the resampler input, so if PA currently 
handles variable frame size without artefacts, it should handle soxr as well. 

The artefacts you described could probably appear in case of large jitter, 
which exceeds PA or sound card buffering capacity. Soxr itself does not 
increase jitter if input signal jitter is higher than the resampler delay 
jitter. In other words, if PA uses variable frame size, and input jitter is 
less than ~20 ms, the resampled signal jitter can be increased. How much the 
increase would be is difficult to say, but I think the upper limit is the 
range of the resampler delay variations.

I ran a few more tests to see how much the delay changes depending on the 
frame size variations:

 - frame sizes 20-25 ms - delay 7-20 ms
 - frame sizes 20-30 ms - delay 6-20 ms
 - frame sizes 20-40 ms - delay 3-20 ms
 - frame sizes 20-50 ms - delay 3-20 ms

So it seems, variable frame sizes can increase jitter to ~17 ms (if the input 
signal has lower jitter). That, of course, corresponds to the parameters I 
used in my test (44.1-48kHz).

As previously, the test code is in git:

https://github.com/Lastique/src_test

You will have to modify code (min_frame_duration and max_frame_duration 
constants) and recompile to see the results for different range of frame 
sizes.

PS: All the above tests were performed with soxr-vhq, as the one that has 
largest delay values.

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

Re: [pulseaudio-discuss] [PATCH 0/4] Add support for libsoxr resampler

[Andrey Semashev]

On Friday 14 November 2014 08:26:18 David Henningsson wrote:
 On 2014-11-13 23:49, Andrey Semashev wrote:
  
  I do not have an explanation for such diverse range of the delay value,
  and
  its dependency on the frame size. It doesn't look like the filter is
  learning from the input in some way since the delay doesn't depend on
  the
  content. Perhaps there is some extensive buffering in the implementation.
 
 Well, the delay must be constant given the parameters. If the delay was
 varying during playback, that would probably cause very interesting
 sound effects, such as music being slightly out of tempo or so...

I've been using soxr-vhq with PA 4.0 on my working machine for about a month 
now, and never heard any sound artefacts.

 What does vary during playback, however, is how big chunks we pass into
 the resampler in every go. Which begs the question if it is the first
 chunk that determines the delay, or...?

So PA uses variable frame size? I can try to modify the test for that. Are 
there any reasonable limits of the frame size?

  For now the bottom line is that the exact delay of the resampler is
  difficult to predict, although it usually does not exceed 20 ms, except
  some rare cases and -vhq. When delay is critical it is better to use
  another resampler, like speex-5, for instance, which consistently stays
  below 1 ms across the board. But I think, such cases are quite
  specialized, and soxr is still very well applicable in general use.
 
 Well, what is quite specialized and general use? If you use your
 computer primarily for gaming and VOIP, then that's what you consider
 general use, and perhaps listening to music so carefully that you
 hear the difference between different resamplers is what you consider
 quite specialized...
 
 So if it was up to me, I'd say let's keep speex-float-1 as the default,
 as it seems to give the best balance between quality, CPU power, and low
 latency.

 With my upstream hat on, I don't mind adding soxr as an option, and with
 my distro hat on, I'm always worried about adding new dependencies...

I'm not changing the default with these patches, soxr is added as an option. 
If not the delay, it would be a very good candidate for being the default, 
though.

As a side note, I think speex-float-1 is a rather poor default as well because 
of its quality. Anyone who cares about the sound he gets will likely change it 
to something like speex-float-3 or 5 anyway. IMHO.

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

[pulseaudio-discuss] [PATCH 2/4] Enabled libsoxr resampler backend.

[Andrey Semashev]

Added ID and names for the resampler presets and also corrected the working 
sample rate deduction to take the new resampler into account. Removed duplicate 
condition checks from the deduction code.
---
 src/pulsecore/resampler.c | 25 -
 src/pulsecore/resampler.h |  4 
 2 files changed, 24 insertions(+), 5 deletions(-)

diff --git a/src/pulsecore/resampler.c b/src/pulsecore/resampler.c
index 183d05f..8974db3 100644
--- a/src/pulsecore/resampler.c
+++ b/src/pulsecore/resampler.c
@@ -111,6 +111,17 @@ static int (* const init_table[])(pa_resampler *r) = {
 [PA_RESAMPLER_AUTO]= NULL,
 [PA_RESAMPLER_COPY]= copy_init,
 [PA_RESAMPLER_PEAKS]   = pa_resampler_peaks_init,
+#ifdef HAVE_SOXR
+[PA_RESAMPLER_SOXR_LQ] = pa_resampler_soxr_init,
+[PA_RESAMPLER_SOXR_MQ] = pa_resampler_soxr_init,
+[PA_RESAMPLER_SOXR_HQ] = pa_resampler_soxr_init,
+[PA_RESAMPLER_SOXR_VHQ]= pa_resampler_soxr_init,
+#else
+[PA_RESAMPLER_SOXR_LQ] = NULL,
+[PA_RESAMPLER_SOXR_MQ] = NULL,
+[PA_RESAMPLER_SOXR_HQ] = NULL,
+[PA_RESAMPLER_SOXR_VHQ]= NULL,
+#endif
 };
 
 static pa_resample_method_t choose_auto_resampler(pa_resample_flags_t flags) {
@@ -278,10 +289,11 @@ static pa_sample_format_t choose_work_format(
 }
 /* Else fall trough */
 case PA_RESAMPLER_PEAKS:
-if (a == PA_SAMPLE_S16NE || b == PA_SAMPLE_S16NE)
-work_format = PA_SAMPLE_S16NE;
-else if (sample_format_more_precise(a, PA_SAMPLE_S16NE) ||
- sample_format_more_precise(b, PA_SAMPLE_S16NE))
+case PA_RESAMPLER_SOXR_MQ:
+case PA_RESAMPLER_SOXR_HQ:
+case PA_RESAMPLER_SOXR_VHQ:
+if (sample_format_more_precise(a, PA_SAMPLE_S16NE) ||
+sample_format_more_precise(b, PA_SAMPLE_S16NE))
 work_format = PA_SAMPLE_FLOAT32NE;
 else
 work_format = PA_SAMPLE_S16NE;
@@ -601,7 +613,10 @@ static const char * const resample_methods[] = {
 ffmpeg,
 auto,
 copy,
-peaks
+peaks,
+soxr-mq,
+soxr-hq,
+soxr-vhq
 };
 
 const char *pa_resample_method_to_string(pa_resample_method_t m) {
diff --git a/src/pulsecore/resampler.h b/src/pulsecore/resampler.h
index 5a84cf0..a0306e7 100644
--- a/src/pulsecore/resampler.h
+++ b/src/pulsecore/resampler.h
@@ -59,6 +59,9 @@ typedef enum pa_resample_method {
 PA_RESAMPLER_AUTO, /* automatic select based on sample format */
 PA_RESAMPLER_COPY,
 PA_RESAMPLER_PEAKS,
+PA_RESAMPLER_SOXR_MQ,
+PA_RESAMPLER_SOXR_HQ,
+PA_RESAMPLER_SOXR_VHQ,
 PA_RESAMPLER_MAX
 } pa_resample_method_t;
 
@@ -163,6 +166,7 @@ int pa_resampler_libsamplerate_init(pa_resampler *r);
 int pa_resampler_peaks_init(pa_resampler *r);
 int pa_resampler_speex_init(pa_resampler *r);
 int pa_resampler_trivial_init(pa_resampler*r);
+int pa_resampler_soxr_init(pa_resampler *r);
 
 /* Resampler-specific quirks */
 bool pa_speex_is_fixed_point(void);
-- 
2.1.0

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

[pulseaudio-discuss] [PATCH 3/4] Added libsoxr detection and optional build of soxr resampler backend.

[Andrey Semashev]

---
 configure.ac| 17 +
 src/Makefile.am |  6 ++
 2 files changed, 23 insertions(+)

diff --git a/configure.ac b/configure.ac
index e91e990..4ae4838 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1133,6 +1133,21 @@ AS_IF([test x$with_speex = xyes  test 
x$HAVE_SPEEX = x0],
 AM_CONDITIONAL([HAVE_SPEEX], [test x$HAVE_SPEEX = x1])
 AS_IF([test x$HAVE_SPEEX = x1], AC_DEFINE([HAVE_SPEEX], 1, [Have speex]))
 
+ soxr (optional) 
+
+AC_ARG_WITH([soxr],
+AS_HELP_STRING([--without-soxr],[Omit soxr (resampling)]))
+
+AS_IF([test x$with_soxr != xno],
+[PKG_CHECK_MODULES(LIBSOXR, [ soxr = 0.1.1 ], HAVE_SOXR=1, HAVE_SOXR=0)],
+HAVE_SOXR=0)
+
+AS_IF([test x$with_soxr = xyes  test x$HAVE_SOXR = x0],
+[AC_MSG_ERROR([*** soxr support not found])])
+
+AM_CONDITIONAL([HAVE_SOXR], [test x$HAVE_SOXR = x1])
+AS_IF([test x$HAVE_SOXR = x1], AC_DEFINE([HAVE_SOXR], 1, [Have soxr]))
+
  Xen support (optional) 
 
 AC_ARG_ENABLE([xen],
@@ -1524,6 +1539,7 @@ AS_IF([test x$HAVE_FFTW = x1], ENABLE_FFTW=yes, 
ENABLE_FFTW=no)
 AS_IF([test x$HAVE_ORC = xyes], ENABLE_ORC=yes, ENABLE_ORC=no)
 AS_IF([test x$HAVE_ADRIAN_EC = x1], ENABLE_ADRIAN_EC=yes, 
ENABLE_ADRIAN_EC=no)
 AS_IF([test x$HAVE_SPEEX = x1], ENABLE_SPEEX=yes, ENABLE_SPEEX=no)
+AS_IF([test x$HAVE_SOXR = x1], ENABLE_SOXR=yes, ENABLE_SOXR=no)
 AS_IF([test x$HAVE_WEBRTC = x1], ENABLE_WEBRTC=yes, ENABLE_WEBRTC=no)
 AS_IF([test x$HAVE_TDB = x1], ENABLE_TDB=yes, ENABLE_TDB=no)
 AS_IF([test x$HAVE_GDBM = x1], ENABLE_GDBM=yes, ENABLE_GDBM=no)
@@ -1585,6 +1601,7 @@ echo 
 Enable orc:${ENABLE_ORC}
 Enable Adrian echo canceller:  ${ENABLE_ADRIAN_EC}
 Enable speex (resampler, AEC): ${ENABLE_SPEEX}
+Enable soxr (resampler):   ${ENABLE_SOXR}
 Enable WebRTC echo canceller:  ${ENABLE_WEBRTC}
 Enable gcov coverage:  ${ENABLE_GCOV}
 Enable unit tests: ${ENABLE_TESTS}
diff --git a/src/Makefile.am b/src/Makefile.am
index 4e60a98..a2d2191 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -1017,6 +1017,12 @@ libpulsecore_@PA_MAJORMINOR@_la_CFLAGS += 
$(LIBSPEEX_CFLAGS)
 libpulsecore_@PA_MAJORMINOR@_la_LIBADD += $(LIBSPEEX_LIBS)
 endif
 
+if HAVE_SOXR
+libpulsecore_@PA_MAJORMINOR@_la_SOURCES += pulsecore/resampler/soxr.c
+libpulsecore_@PA_MAJORMINOR@_la_CFLAGS += $(LIBSOXR_CFLAGS)
+libpulsecore_@PA_MAJORMINOR@_la_LIBADD += $(LIBSOXR_LIBS)
+endif
+
 if HAVE_LIBSAMPLERATE
 libpulsecore_@PA_MAJORMINOR@_la_SOURCES += pulsecore/resampler/libsamplerate.c
 libpulsecore_@PA_MAJORMINOR@_la_CFLAGS += $(LIBSAMPLERATE_CFLAGS)
-- 
2.1.0

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

[pulseaudio-discuss] [PATCH v2 0/4] Add support for libsoxr resampler

[Andrey Semashev]

This is an updated set of patches first announced and discussed here:

http://comments.gmane.org/gmane.comp.audio.pulseaudio.general/22158

Changes to the original patches:

* Removed the -lq quality preset, only -mq, -hq and -vhq presets are left.
* Removed the fix to the sample_format_more_precise function as it was factored 
out to a separate patch, which was committed.
* Changed the asserts in switch/case statements to the pa_assert_not_reached() 
macro and also some comments as suggested.
* Explicitly provide runtime_spec with thread number 1 to soxr_create so that 
we're guaranteed to not use multithreading. This is equivalent to the previous 
code that relied on the default.
* Changed choose_work_format() so that soxr uses the common case branch rather 
than its own. Removed the duplicate condition from it to simplify code slightly.
* Updated docs so that it better describes pros and cons of the new resampler 
and its presets.

Andrey Semashev (4):
  Added libsoxr resampler backend.
  Enabled libsoxr resampler backend.
  Added libsoxr detection and optional build of soxr resampler backend.
  Added documentation for soxr resampling methods.

 configure.ac   |  17 +
 man/pulse-daemon.conf.5.xml.in |  14 +++-
 src/Makefile.am|   6 ++
 src/pulsecore/resampler.c  |  25 --
 src/pulsecore/resampler.h  |   4 +
 src/pulsecore/resampler/soxr.c | 170 +
 6 files changed, 228 insertions(+), 8 deletions(-)
 create mode 100644 src/pulsecore/resampler/soxr.c

-- 
2.1.0

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

[pulseaudio-discuss] [PATCH 1/4] Added libsoxr resampler backend.

[Andrey Semashev]

The new backend supports 3 quality levels: mq, hq and vhq; 16 integer and 
32-bit float samples. Discussion and quality assessment are here:

http://comments.gmane.org/gmane.comp.audio.pulseaudio.general/22158
---
 src/pulsecore/resampler/soxr.c | 170 +
 1 file changed, 170 insertions(+)
 create mode 100644 src/pulsecore/resampler/soxr.c

diff --git a/src/pulsecore/resampler/soxr.c b/src/pulsecore/resampler/soxr.c
new file mode 100644
index 000..c2fd8ee
--- /dev/null
+++ b/src/pulsecore/resampler/soxr.c
@@ -0,0 +1,170 @@
+/***
+  This file is part of PulseAudio.
+
+  Copyright 2014 Andrey Semashev
+
+  PulseAudio is free software; you can redistribute it and/or modify
+  it under the terms of the GNU Lesser General Public License as published
+  by the Free Software Foundation; either version 2.1 of the License,
+  or (at your option) any later version.
+
+  PulseAudio is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with PulseAudio; if not, write to the Free Software
+  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
+  USA.
+***/
+
+#ifdef HAVE_CONFIG_H
+#include config.h
+#endif
+
+#include stddef.h
+#include soxr.h
+
+#include pulsecore/resampler.h
+
+static unsigned resampler_soxr_resample(pa_resampler *r, const pa_memchunk 
*input, unsigned in_n_frames,
+pa_memchunk *output, unsigned 
*out_n_frames) {
+soxr_t state;
+void *in, *out;
+size_t consumed = 0, produced = 0;
+
+pa_assert(r);
+pa_assert(input);
+pa_assert(output);
+pa_assert(out_n_frames);
+
+state = r-impl.data;
+pa_assert(state);
+
+in = pa_memblock_acquire_chunk(input);
+out = pa_memblock_acquire_chunk(output);
+
+pa_assert_se(soxr_process(state, in, in_n_frames, consumed, out, 
*out_n_frames, produced) == 0);
+
+pa_memblock_release(input-memblock);
+pa_memblock_release(output-memblock);
+
+*out_n_frames = produced;
+
+return in_n_frames - consumed;
+}
+
+static void resampler_soxr_free(pa_resampler *r) {
+pa_assert(r);
+
+if (!r-impl.data)
+return;
+
+soxr_delete(r-impl.data);
+r-impl.data = NULL;
+}
+
+static void resampler_soxr_reset(pa_resampler *r) {
+soxr_t old_state;
+
+pa_assert(r);
+
+/*
+ * soxr_clear() makes soxr_process() crash afterwards,
+ * so don't use this function until libsoxr is fixed.
+ *
+ * soxr_clear(r-impl.data);
+ */
+
+old_state = r-impl.data;
+r-impl.data = NULL;
+
+if (pa_resampler_soxr_init(r) == 0) {
+if (old_state)
+soxr_delete(old_state);
+} else {
+r-impl.data = old_state;
+pa_log_error(Failed to reset libsoxr context);
+}
+}
+
+static void resampler_soxr_update_rates(pa_resampler *r) {
+soxr_t old_state;
+
+pa_assert(r);
+
+/* There is no update method in libsoxr,
+ * so just re-create the resampler context */
+
+old_state = r-impl.data;
+r-impl.data = NULL;
+
+if (pa_resampler_soxr_init(r) == 0) {
+if (old_state)
+soxr_delete(old_state);
+} else {
+r-impl.data = old_state;
+pa_log_error(Failed to update libsoxr sample rates);
+}
+}
+
+int pa_resampler_soxr_init(pa_resampler *r) {
+soxr_t state;
+soxr_datatype_t io_format;
+soxr_io_spec_t io_spec;
+soxr_runtime_spec_t runtime_spec;
+unsigned long quality_recipe;
+soxr_quality_spec_t quality;
+soxr_error_t err = NULL;
+
+pa_assert(r);
+
+switch (r-work_format) {
+case PA_SAMPLE_S16NE:
+io_format = SOXR_INT16_I;
+break;
+case PA_SAMPLE_FLOAT32NE:
+io_format = SOXR_FLOAT32_I;
+break;
+default:
+pa_assert_not_reached();
+return -1;
+}
+
+io_spec = soxr_io_spec(io_format, io_format);
+
+/* Resample in one thread. Multithreading makes
+ * performance worse with small chunks of audio. */
+runtime_spec = soxr_runtime_spec(1);
+
+switch (r-method) {
+case PA_RESAMPLER_SOXR_MQ:
+quality_recipe = SOXR_MQ | SOXR_LINEAR_PHASE;
+break;
+case PA_RESAMPLER_SOXR_VHQ:
+quality_recipe = SOXR_VHQ | SOXR_LINEAR_PHASE;
+break;
+default:
+pa_assert_not_reached();
+case PA_RESAMPLER_SOXR_HQ:
+quality_recipe = SOXR_HQ | SOXR_LINEAR_PHASE;
+break;
+}
+
+quality = soxr_quality_spec(quality_recipe, 0);
+
+state = soxr_create(r-i_ss.rate, r-o_ss.rate, r-work_channels, err, 
io_spec, quality, runtime_spec);
+if (!state) {
+pa_log_error(Failed to create libsoxr resampler context: %s

[pulseaudio-discuss] [PATCH 4/4] Added documentation for soxr resampling methods.

[Andrey Semashev]

---
 man/pulse-daemon.conf.5.xml.in | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/man/pulse-daemon.conf.5.xml.in b/man/pulse-daemon.conf.5.xml.in
index 754312e..f8ba9b4 100644
--- a/man/pulse-daemon.conf.5.xml.in
+++ b/man/pulse-daemon.conf.5.xml.in
@@ -88,7 +88,8 @@ USA.
   optsrc-sinc-medium-quality/opt, optsrc-sinc-fastest/opt,
   optsrc-zero-order-hold/opt, optsrc-linear/opt,
   opttrivial/opt, optspeex-float-N/opt,
-  optspeex-fixed-N/opt, optffmpeg/opt. See the
+  optspeex-fixed-N/opt, optffmpeg/opt, optsoxr-mq/opt,
+  optsoxr-hq/opt, optsoxr-vhq/opt. See the
   documentation of libsamplerate and speex for explanations of the
   different src- and speex- methods, respectively. The method
   opttrivial/opt is the most basic algorithm implemented. If
@@ -98,8 +99,15 @@ USA.
   exist in two flavours: optfixed/opt and optfloat/opt. The former 
uses fixed point
   numbers, the latter relies on floating point numbers. On most
   desktop CPUs the float point resampler is a lot faster, and it
-  also offers slightly better quality. See the output of
-  optdump-resample-methods/opt for a complete list of all
+  also offers slightly better quality. The soxr- family methods
+  are based on libsoxr, a resampler library from SoX sound processing 
utility.
+  The mq variant has the best performance of the three. The hq is more 
expensive
+  and is considered the best choice for audio of up to 16 bits per sample. 
The vhq variant
+  has more precision than hq and is more suitable for larger samples. The 
Soxr resamplers
+  generally offer better quality at less CPU compared to other resamplers, 
such as speex.
+  The downside is that it can add a significant delay to the output
+  (usually, up to around 20 ms, in rare cases more).
+  See the output of optdump-resample-methods/opt for a complete list 
of all
   available resamplers. Defaults to optspeex-float-1/opt. The
   opt--resample-method/opt command line option takes precedence.
   Note that some modules overwrite or allow overwriting of the
-- 
2.1.0

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

[pulseaudio-discuss] [PATCH 5/4] Removed leftover bits referring to soxr-lq.

[Andrey Semashev]

---
These bits were left by accident when I was removing the soxr-lq from my 
patches.

 src/pulsecore/resampler.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/src/pulsecore/resampler.c b/src/pulsecore/resampler.c
index 8974db3..17919a3 100644
--- a/src/pulsecore/resampler.c
+++ b/src/pulsecore/resampler.c
@@ -112,12 +112,10 @@ static int (* const init_table[])(pa_resampler *r) = {
 [PA_RESAMPLER_COPY]= copy_init,
 [PA_RESAMPLER_PEAKS]   = pa_resampler_peaks_init,
 #ifdef HAVE_SOXR
-[PA_RESAMPLER_SOXR_LQ] = pa_resampler_soxr_init,
 [PA_RESAMPLER_SOXR_MQ] = pa_resampler_soxr_init,
 [PA_RESAMPLER_SOXR_HQ] = pa_resampler_soxr_init,
 [PA_RESAMPLER_SOXR_VHQ]= pa_resampler_soxr_init,
 #else
-[PA_RESAMPLER_SOXR_LQ] = NULL,
 [PA_RESAMPLER_SOXR_MQ] = NULL,
 [PA_RESAMPLER_SOXR_HQ] = NULL,
 [PA_RESAMPLER_SOXR_VHQ]= NULL,
-- 
2.1.0

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

Re: [pulseaudio-discuss] [PATCH 0/4] Add support for libsoxr resampler

[Andrey Semashev]

On Thursday 13 November 2014 11:32:09 you wrote:
 On Thu, Nov 13, 2014 at 8:33 AM, David Henningsson
 
 david.hennings...@canonical.com wrote:
  On 2014-11-11 22:39, Andrey Semashev wrote:
  In short, libsoxr is almost always faster than speex, and introduces much
  less distortions. Its passband frequency is slightly lower than speex
  though, and it can add a delay up to 20 ms in some cases.
  
  I'm interested in knowing more about the delay. What are some cases?
 
 Some cases means some sample rate combinations. In my tests I
 measured the delay of the resampler, and it was ~20 ms max. I don't
 have the results accessible now, I'll add them tonight to the results
 page.

Ok, here are some interesting results.

1. The delay does not depend on the input format (int16 vs float) or content. 
I tried with two different input pieces of content.

2. The delay _does_ depend on the input frame size (i.e. the amount of input 
samples you pass to the resampler in one chunk). I tested for frame sizes of 
20 and 100 samples per channel. There isn't a particularly obvious relation 
between the frame size and the delay.

3. The delay is typically lower for low quality presets (-lq, -mq), but that's 
not always the case.

4. The delay is typically lower for 2-fold sample rate conversions (i.e. 48kHz 
- 96kHz).

5. The delay varies in a wide range between different sample rate 
combinations. Different quality presets, on the other hand, are not as 
different. There are cases of 20 ms delay on all three -mq, -hq and -vhq 
presets, as well as there are cases of 5 ms.

6. With frame size 20 min/max delay values are:

   -mq: 1.917/20.604 ms
   -hq: 2.708/20.000 ms
   -vhq: 4.208/20.000 ms

  In case of 44.1 kHz, 16 bit, int - 48 kHz it is 20.604/20.000/20.000 ms in 
the three presets.

7. With frame size 100 min/max delay values are:

   -mq: 2.771/12.336 ms
   -hq: 7.104/16.531 ms
   -vhq: 5.250/27.256 ms

  In case of 44.1 kHz, 16 bit, int - 48 kHz it is 2.771/7.104/15.292 ms in 
the three presets.

  Note that 27.256 for -vhq in this case is larger than I stated in my initial 
announcement and the docs patch. I had not tested frame size 100 at that time. 
I will update the docs patch accordingly (probably, by describing the delay 
range more loosely).

I do not have an explanation for such diverse range of the delay value, and 
its dependency on the frame size. It doesn't look like the filter is 
learning from the input in some way since the delay doesn't depend on the 
content. Perhaps there is some extensive buffering in the implementation.

I can try and perform more tests with different frame sizes in attempt to 
determine the approximate maximum delay. I suspect, even after such testing is 
conducted I won't be absolutely sure that the discovered upper value won't 
ever be exceeded in some other case I did not cover. I can, however, test with 
the frame size that is used in PulseAudio, if such fixed or typical value 
exists (does it?).

For now the bottom line is that the exact delay of the resampler is difficult 
to predict, although it usually does not exceed 20 ms, except some rare cases 
and -vhq. When delay is critical it is better to use another resampler, like 
speex-5, for instance, which consistently stays below 1 ms across the board. 
But I think, such cases are quite specialized, and soxr is still very well 
applicable in general use.


The full results are available here, at the bottom of the page:

http://lastique.github.io/src_test/

The code of the test and the test waves are in git:

https://github.com/Lastique/src_test

If you want to reproduce the results:

1. Checkout the git repository. Warning: it does contain all the data you can 
see on the results page; it's a little short to 7 GiB in total on disk.
2. Build the test project (cmake, C++11, libsndfile-dev, libspeexdsp-dev and 
libsoxr-dev are required).
3. Checkout gh-pages branch. In the data/original folder there are the 
original signals used as input. You can use your own input files as well 
(uncompressed wavs, 16-bit int or 32-bit float).
4. Run the test project:

  ./src_test input file resampler output sample rate output file

  For example:

  ./src_test 44kHz_16-bit.wav soxr-hq 48000 soxr-hq-48kHz.wav

There is also test.sh in the master branch that can be used to automatically 
run all tests you can see on the results page.
5. You will see the measured delay value among the output of the test program.

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

Re: [pulseaudio-discuss] [PATCH 0/4] Add support for libsoxr resampler

[Andrey Semashev]

On Wed, Nov 12, 2014 at 12:26 PM, Alexander E. Patrakov
patra...@gmail.com wrote:

 We generally don't need a zoo of resamplers. But you have definitely changed
 something important from an earlier submission by Peter Meerwald so that the
 CPU figure became much better. I guess, that's SOXR_LINEAR_PHASE - that's
 the only obvious change.

SOXR_LINEAR_PHASE is 0, I added it mostly for documentation purpose,
in case if someone wants to add more modes with different phase
response presets. There is also another difference in that I
explicitly specify interleaved sample formats, although it is
numerically equivalent to those without the _I suffix.

I think, the essential difference is quality. Peter's patches use
SOXR_QQ, while mine use other presets. I didn't add QQ because I don't
see much point in this mode.

I also noticed unusual relation between quality and CPU consumption.
You can see that in my results LQ actually appears the most consuming
in some cases. I don't have a good explanation for this, my guess is
that this could be related to different math precision and
optimization. I think the library uses different precision for math on
different quality levels (i.e. double in VHQ, float in HQ, etc.), and
it does have some optimizations for SSE. It's possible that LQ path is
not as optimized. One would probably have to inspect libsoxr code to
tell for sure.

 Here are the facts, applicable to 44100 - 48000 Hz resampling, as required
 by some sound cards when playing back CD rips:

  * Speex-float-5 never introduces audible distortions, even on
 specifically-crafted testcases at insane volume in an otherwise absolutely
 quiet room. So even better quality never makes sense - unless we are
 talking about non-human listeners.
  * Speex-float-1 (the current default) does not introduce audible
 distortions on music that you can buy in shops (or download), but does
 create audible artifacts on specially prepared test cases.
  * SOXR, even at its LQ setting (which, according to prior tests, is good
 enough) and with THIS set of patches, is indeed slightly faster than
 speex-float-1.

 Statements about distortion audibility are based on the model described in
 this scientific paper:

 http://www.mp3-tech.org/programmer/docs/6_Heusdens.pdf

 Distortions caused by removal of high frequencies, as well as any other
 distortions, would have been counted as audible if a person could detect
 that in an ABX test. The nuance here (with auditory masking as its
 scientific name) is that the ear becomes less sensitive to very high
 frequencies when there is something else in the air - and in typical music,
 this something else definitely exists in a sufficient quantity.

Thanks for the reference and all the information.

I didn't do a blind test to detect the audible difference, all I can
say is my own impressions. I have a locally patched PulseAudio 4.0 and
I'm using soxr-vhq preset resampling everything to 96kHz (I have
records in 96kHz that I don't want to resample). The difference with
speex-float-5, which I used previously, is indeed rather subtle. I'd
say, the sound is a bit more clear, instrument separation is better,
especially in bass. But that's all subjective, of course, so it should
be taken with a big grain of salt. In any case, soxr-vhq is clearly
faster than speex-float-5, so at the very least it's a performance
improvement for me.

 I will recheck the quality separately later today, in order to verify that
 it is still as good as in the previous tests. Please don't merge the patches
 until this is done.

Thanks, I'd be interested in the results.
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH 1/4] Added libsoxr resampler backend.

[Andrey Semashev]

On Wed, Nov 12, 2014 at 1:15 PM, Peter Meerwald pme...@pmeerw.net wrote:

 +switch (r-work_format) {
 +case PA_SAMPLE_S16NE:
 +io_format = SOXR_INT16_I;
 +break;
 +case PA_SAMPLE_S32NE:
 +io_format = SOXR_INT32_I;
 +break;

 currently work_format is either S16NE or FLOAT32NE;
 I think more work is needed to add S32NE as a work format

Yes, I found that out when I was adding this backend to the general
code in resampler.c. I decided to leave this case nevertheless, so
that if resampler.c is enhanced, soxr backend doesn't need any
changes.

If that's considered unneeded clutter I can remove it no problem.

 +case PA_SAMPLE_FLOAT32NE:
 +io_format = SOXR_FLOAT32_I;
 +break;
 +default:
 +pa_assert(0  Unsupported sample format for libsoxr);
 +return -1;
 +}
 +
 +io_spec = soxr_io_spec(io_format, io_format);
 +
 +switch (r-method) {
 +case PA_RESAMPLER_SOXR_LQ:
 +quality_recipe = SOXR_LQ | SOXR_LINEAR_PHASE;
 +break;
 +case PA_RESAMPLER_SOXR_MQ:
 +quality_recipe = SOXR_MQ | SOXR_LINEAR_PHASE;
 +break;
 +case PA_RESAMPLER_SOXR_VHQ:
 +quality_recipe = SOXR_VHQ | SOXR_LINEAR_PHASE;
 +break;
 +default:
 +pa_assert(0  Unexpected libsoxr resampling method);

 0  ???

It's a common approach for injecting a message into the assertion
failure. The C runtime typically displays the condition that fails,
and in this case it will include the message. It helps debugging.
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH 1/4] Added libsoxr resampler backend.

[Andrey Semashev]

On Wed, Nov 12, 2014 at 3:00 PM, Alexander E. Patrakov
patra...@gmail.com wrote:
 12.11.2014 16:57, Andrey Semashev wrote:

 It's a common approach for injecting a message into the assertion
 failure. The C runtime typically displays the condition that fails,
 and in this case it will include the message. It helps debugging.


 We have pa_assert_not_reached just for that. It doesn't have a way to inject
 a custom message, but it does log a file and a line.

Ok, I will use it then.
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH 2/4] Enabled libsoxr resampler backend.

[Andrey Semashev]

On Wed, Nov 12, 2014 at 1:03 PM, Peter Meerwald pme...@pmeerw.net wrote:

 Also fixed a bug in sample_format_more_precise for 32-bit integer sample 
 formats.

 can you please split out the bug fix as a separate patch?
 it can be readily applied

Ok, will do.
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH 0/4] Add support for libsoxr resampler

[Andrey Semashev]

On Wed, Nov 12, 2014 at 2:30 PM, Alexander E. Patrakov
patra...@gmail.com wrote:
 12.11.2014 15:59, Andrey Semashev wrote:

 On Wed, Nov 12, 2014 at 12:26 PM, Alexander E. Patrakov
 patra...@gmail.com wrote:


 We generally don't need a zoo of resamplers. But you have definitely
 changed
 something important from an earlier submission by Peter Meerwald so that
 the
 CPU figure became much better. I guess, that's SOXR_LINEAR_PHASE - that's
 the only obvious change.


 SOXR_LINEAR_PHASE is 0, I added it mostly for documentation purpose,
 in case if someone wants to add more modes with different phase
 response presets. There is also another difference in that I
 explicitly specify interleaved sample formats, although it is
 numerically equivalent to those without the _I suffix.

 I think, the essential difference is quality. Peter's patches use
 SOXR_QQ, while mine use other presets. I didn't add QQ because I don't
 see much point in this mode.

 Indeed, QQ is just cubic interpolation, worse than speex-float-0. However, I
 have tried to change that to other values in the old patches, and the result
 was a good resampler that ate a lot more CPU than speex-float-5. Note,
 however, that the test was done with a Haswell (year 2013) earlier and with
 an Arrandale (year 2010) now.

I also noticed that Peter's patch supplied runtime_spec to
soxr_create(), with the number of threads equal to 0 (i.e.
auto-detected). In this case the library uses OpenMP to parallelize
some operations. In my patch the default is used, which means 1 thread
and no OpenMP. On small frames of audio, the overhead of OpenMP can
probably outweigh the benefit.
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH 0/4] Add support for libsoxr resampler

[Andrey Semashev]

On Wednesday 12 November 2014 20:03:48 Alexander E. Patrakov wrote:
 12.11.2014 14:26, Alexander E. Patrakov пишет:
  I will recheck the quality separately later today, in order to verify
  that it is still as good as in the previous tests. Please don't merge
  the patches until this is done.
 
 Done. The -mq, -hq and -vhq variants of the resampler never produce
 audible distortions. The -lq variant sometimes does, by means of
 suppressing very high frequencies, but this is relevant to artificial
 tests only, and only if the listener knows that these frequencies are
 supposed to be there. Thus, quality is on par with speex-float-5, the
 CPU consumption is even better than with speex-float-1. Conclusion:
 
 *** the patches are generally acceptable ***

Great! And thanks a lot for the quality data and information. I will send v2 
patches in a day or two.

 However, because the low-quality and high-quality versions eat very
 similar amount of CPU time, I'd just expose a single (high or very high)
 quality setting.

Given that -lq is actually slower than -mq in some cases and has worse 
quality, I agree there is no point in keeping it.

However, the other three presets do have different performance and quality. In 
my test results [1] -mq is about 2 times faster than -vhq, and -hq is 
somewhere in between. Performance wise, there should be no problem with -vhq 
on modern CPUs, but maybe the little extra would be desired in embedded domain 
to conserve battery. Do you think we could keep the three presets: -mq, -hq 
and -vhq?

[1]: http://lastique.github.io/src_test/

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

[pulseaudio-discuss] [PATCH] Fix sample_format_more_precise for the case of comparing two PA_SAMPLE_S32BE.

[Andrey Semashev]

---
 src/pulsecore/resampler.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/pulsecore/resampler.c b/src/pulsecore/resampler.c
index 8b30c24..183d05f 100644
--- a/src/pulsecore/resampler.c
+++ b/src/pulsecore/resampler.c
@@ -234,7 +234,7 @@ static bool sample_format_more_precise(pa_sample_format_t 
a, pa_sample_format_t
 case PA_SAMPLE_S32LE:
 case PA_SAMPLE_S32BE:
 if (b == PA_SAMPLE_FLOAT32LE || b == PA_SAMPLE_FLOAT32BE ||
-b == PA_SAMPLE_S32LE || b == PA_SAMPLE_FLOAT32BE)
+b == PA_SAMPLE_S32LE || b == PA_SAMPLE_S32BE)
 return false;
 else
 return true;
-- 
2.1.0

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

Re: [pulseaudio-discuss] [PATCH 0/4] Add support for libsoxr resampler

[Andrey Semashev]

On Thu, Nov 13, 2014 at 8:33 AM, David Henningsson
david.hennings...@canonical.com wrote:


 On 2014-11-11 22:39, Andrey Semashev wrote:

 In short, libsoxr is almost always faster than speex, and introduces much
 less distortions. Its passband frequency is slightly lower than speex
 though, and it can add a delay up to 20 ms in some cases.


 I'm interested in knowing more about the delay. What are some cases?

Some cases means some sample rate combinations. In my tests I
measured the delay of the resampler, and it was ~20 ms max. I don't
have the results accessible now, I'll add them tonight to the results
page.

BTW, the test code is available here:

https://github.com/lastique/src_test

 I can think of at least two scenarios where this means trouble:

  * VOIP, where you need as low latency as possible, adding 20 ms more is not
 that great

  * Lip-sync, the limit is about ~50 ms, and thus 20 ms is quite a bit of
 that budget

Yes, for real time communication this can be a nuisance, although in
this use case 20 ms usually isn't noticable and is exceeded by network
and other components latency. If you also have video exchange, you
should take into account its own delay, and it can easily exceed that
amount too.

I can add that the delay can be much more critical for real time
recording with monitor, which is used by musicians. Hardcore gamers
also strive for minimum latency, although I'm not sure if the
resampler delay is significant in this case (AFAIK, human reaction
time is hundreds ms anyway [1]). Anyway, if delay is critical, soxr is
probably not the best choice.

 The second problem could be solved if soxr could tell us the delay and we
 could account for it. Is this possible? (I skimmed through the patches but
 did not find anything related)

The library offers the soxr_delay() function that returns the current
delay. I suppose, it should give the result that is needed except at
the very start, when the resampler is filling. I did not use that
function in my patches because there seems to be no API in PA to query
the resampler delay.

[1]: 
http://enterthesingularity.blogspot.ru/2010/04/latency-human-response-time-in-current.html
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH 0/4] Add support for libsoxr resampler

[Andrey Semashev]

On Thu, Nov 13, 2014 at 7:12 AM, Alexander E. Patrakov
patra...@gmail.com wrote:
 13.11.2014 01:16, Andrey Semashev пишет:

 However, the other three presets do have different performance and
 quality. In
 my test results [1] -mq is about 2 times faster than -vhq, and -hq is
 somewhere in between. Performance wise, there should be no problem with
 -vhq
 on modern CPUs, but maybe the little extra would be desired in embedded
 domain
 to conserve battery.


 Well, in the embedded domain, there is usually no FPU or a bad FPU, and a
 different resampler (hint: speex-fixed-X) is needed anyway :)

Most current ARM CPUs have NEON, and libsoxr has optimizations for it.
I didn't benchmark it, but since soxr is faster than speex on x86, it
seems possible for it to be faster on ARM as well. It'be interesting
to bench it though.
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

[pulseaudio-discuss] [PATCH 1/4] Added libsoxr resampler backend.

[Andrey Semashev]

The new backend supports 4 quality levels: lq, mq, hq and vhq; 16 and 32-bit 
integer samples and 32-bit float samples. The libsoxr resampler generally 
offers better quality and speed compared to speex.
---
 src/pulsecore/resampler/soxr.c | 168 +
 1 file changed, 168 insertions(+)
 create mode 100644 src/pulsecore/resampler/soxr.c

diff --git a/src/pulsecore/resampler/soxr.c b/src/pulsecore/resampler/soxr.c
new file mode 100644
index 000..ba45d36
--- /dev/null
+++ b/src/pulsecore/resampler/soxr.c
@@ -0,0 +1,168 @@
+/***
+  This file is part of PulseAudio.
+
+  Copyright 2014 Andrey Semashev
+
+  PulseAudio is free software; you can redistribute it and/or modify
+  it under the terms of the GNU Lesser General Public License as published
+  by the Free Software Foundation; either version 2.1 of the License,
+  or (at your option) any later version.
+
+  PulseAudio is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with PulseAudio; if not, write to the Free Software
+  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
+  USA.
+***/
+
+#ifdef HAVE_CONFIG_H
+#include config.h
+#endif
+
+#include stddef.h
+#include soxr.h
+
+#include pulsecore/resampler.h
+
+static unsigned resampler_soxr_resample(pa_resampler *r, const pa_memchunk 
*input, unsigned in_n_frames,
+pa_memchunk *output, unsigned 
*out_n_frames) {
+soxr_t state;
+void *in, *out;
+size_t consumed = 0, produced = 0;
+
+pa_assert(r);
+pa_assert(input);
+pa_assert(output);
+pa_assert(out_n_frames);
+
+state = r-impl.data;
+pa_assert(state);
+
+in = pa_memblock_acquire_chunk(input);
+out = pa_memblock_acquire_chunk(output);
+
+pa_assert_se(soxr_process(state, in, in_n_frames, consumed, out, 
*out_n_frames, produced) == 0);
+
+pa_memblock_release(input-memblock);
+pa_memblock_release(output-memblock);
+
+*out_n_frames = produced;
+
+return in_n_frames - consumed;
+}
+
+static void resampler_soxr_free(pa_resampler *r) {
+pa_assert(r);
+
+if (!r-impl.data)
+return;
+
+soxr_delete(r-impl.data);
+r-impl.data = NULL;
+}
+
+static void resampler_soxr_reset(pa_resampler *r) {
+soxr_t old_state;
+
+pa_assert(r);
+
+/* This makes soxr_process() crash afterwards,
+   so don't use this function until libsoxr is fixed.
+soxr_clear(r-impl.data); */
+
+old_state = r-impl.data;
+r-impl.data = NULL;
+
+if (pa_resampler_soxr_init(r) == 0) {
+if (old_state)
+soxr_delete(old_state);
+} else {
+r-impl.data = old_state;
+pa_log_error(Failed to reset libsoxr context);
+}
+}
+
+static void resampler_soxr_update_rates(pa_resampler *r) {
+soxr_t old_state;
+
+pa_assert(r);
+
+/* There is no update method in libsoxr,
+   so just re-create the resampler context */
+
+old_state = r-impl.data;
+r-impl.data = NULL;
+
+if (pa_resampler_soxr_init(r) == 0) {
+if (old_state)
+soxr_delete(old_state);
+} else {
+r-impl.data = old_state;
+pa_log_error(Failed to update libsoxr sample rates);
+}
+}
+
+int pa_resampler_soxr_init(pa_resampler *r) {
+soxr_t state;
+soxr_datatype_t io_format;
+soxr_io_spec_t io_spec;
+unsigned long quality_recipe;
+soxr_quality_spec_t quality;
+soxr_error_t err = NULL;
+
+pa_assert(r);
+
+switch (r-work_format) {
+case PA_SAMPLE_S16NE:
+io_format = SOXR_INT16_I;
+break;
+case PA_SAMPLE_S32NE:
+io_format = SOXR_INT32_I;
+break;
+case PA_SAMPLE_FLOAT32NE:
+io_format = SOXR_FLOAT32_I;
+break;
+default:
+pa_assert(0  Unsupported sample format for libsoxr);
+return -1;
+}
+
+io_spec = soxr_io_spec(io_format, io_format);
+
+switch (r-method) {
+case PA_RESAMPLER_SOXR_LQ:
+quality_recipe = SOXR_LQ | SOXR_LINEAR_PHASE;
+break;
+case PA_RESAMPLER_SOXR_MQ:
+quality_recipe = SOXR_MQ | SOXR_LINEAR_PHASE;
+break;
+case PA_RESAMPLER_SOXR_VHQ:
+quality_recipe = SOXR_VHQ | SOXR_LINEAR_PHASE;
+break;
+default:
+pa_assert(0  Unexpected libsoxr resampling method);
+case PA_RESAMPLER_SOXR_HQ:
+quality_recipe = SOXR_HQ | SOXR_LINEAR_PHASE;
+break;
+}
+
+quality = soxr_quality_spec(quality_recipe, 0);
+
+state = soxr_create(r-i_ss.rate, r-o_ss.rate, r-work_channels, err, 
io_spec, quality, NULL);
+if (!state) {
+pa_log_error(Failed to create libsoxr

[pulseaudio-discuss] [PATCH 2/4] Enabled libsoxr resampler backend.

[Andrey Semashev]

Also fixed a bug in sample_format_more_precise for 32-bit integer sample 
formats.
---
 src/pulsecore/resampler.c | 32 ++--
 src/pulsecore/resampler.h |  5 +
 2 files changed, 35 insertions(+), 2 deletions(-)

diff --git a/src/pulsecore/resampler.c b/src/pulsecore/resampler.c
index 8b30c24..66101f6 100644
--- a/src/pulsecore/resampler.c
+++ b/src/pulsecore/resampler.c
@@ -111,6 +111,17 @@ static int (* const init_table[])(pa_resampler *r) = {
 [PA_RESAMPLER_AUTO]= NULL,
 [PA_RESAMPLER_COPY]= copy_init,
 [PA_RESAMPLER_PEAKS]   = pa_resampler_peaks_init,
+#ifdef HAVE_SOXR
+[PA_RESAMPLER_SOXR_LQ] = pa_resampler_soxr_init,
+[PA_RESAMPLER_SOXR_MQ] = pa_resampler_soxr_init,
+[PA_RESAMPLER_SOXR_HQ] = pa_resampler_soxr_init,
+[PA_RESAMPLER_SOXR_VHQ]= pa_resampler_soxr_init,
+#else
+[PA_RESAMPLER_SOXR_LQ] = NULL,
+[PA_RESAMPLER_SOXR_MQ] = NULL,
+[PA_RESAMPLER_SOXR_HQ] = NULL,
+[PA_RESAMPLER_SOXR_VHQ]= NULL,
+#endif
 };
 
 static pa_resample_method_t choose_auto_resampler(pa_resample_flags_t flags) {
@@ -234,7 +245,7 @@ static bool sample_format_more_precise(pa_sample_format_t 
a, pa_sample_format_t
 case PA_SAMPLE_S32LE:
 case PA_SAMPLE_S32BE:
 if (b == PA_SAMPLE_FLOAT32LE || b == PA_SAMPLE_FLOAT32BE ||
-b == PA_SAMPLE_S32LE || b == PA_SAMPLE_FLOAT32BE)
+b == PA_SAMPLE_S32LE || b == PA_SAMPLE_S32BE)
 return false;
 else
 return true;
@@ -287,6 +298,19 @@ static pa_sample_format_t choose_work_format(
 work_format = PA_SAMPLE_S16NE;
 break;
 
+case PA_RESAMPLER_SOXR_LQ:
+case PA_RESAMPLER_SOXR_MQ:
+case PA_RESAMPLER_SOXR_HQ:
+case PA_RESAMPLER_SOXR_VHQ:
+/* Note: libsoxr can potentially work with PA_SAMPLE_S32NE as well 
*/
+if (!map_required 
+(a == PA_SAMPLE_S16LE || a == PA_SAMPLE_S16BE || 
sample_format_more_precise(PA_SAMPLE_S16NE, a)) 
+(b == PA_SAMPLE_S16LE || b == PA_SAMPLE_S16BE || 
sample_format_more_precise(PA_SAMPLE_S16NE, b)))
+work_format = PA_SAMPLE_S16NE;
+else
+work_format = PA_SAMPLE_FLOAT32NE;
+break;
+
 default:
 work_format = PA_SAMPLE_FLOAT32NE;
 }
@@ -601,7 +625,11 @@ static const char * const resample_methods[] = {
 ffmpeg,
 auto,
 copy,
-peaks
+peaks,
+soxr-lq,
+soxr-mq,
+soxr-hq,
+soxr-vhq
 };
 
 const char *pa_resample_method_to_string(pa_resample_method_t m) {
diff --git a/src/pulsecore/resampler.h b/src/pulsecore/resampler.h
index 5a84cf0..ebb7050 100644
--- a/src/pulsecore/resampler.h
+++ b/src/pulsecore/resampler.h
@@ -59,6 +59,10 @@ typedef enum pa_resample_method {
 PA_RESAMPLER_AUTO, /* automatic select based on sample format */
 PA_RESAMPLER_COPY,
 PA_RESAMPLER_PEAKS,
+PA_RESAMPLER_SOXR_LQ,
+PA_RESAMPLER_SOXR_MQ,
+PA_RESAMPLER_SOXR_HQ,
+PA_RESAMPLER_SOXR_VHQ,
 PA_RESAMPLER_MAX
 } pa_resample_method_t;
 
@@ -163,6 +167,7 @@ int pa_resampler_libsamplerate_init(pa_resampler *r);
 int pa_resampler_peaks_init(pa_resampler *r);
 int pa_resampler_speex_init(pa_resampler *r);
 int pa_resampler_trivial_init(pa_resampler*r);
+int pa_resampler_soxr_init(pa_resampler *r);
 
 /* Resampler-specific quirks */
 bool pa_speex_is_fixed_point(void);
-- 
2.1.0

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

[pulseaudio-discuss] [PATCH 3/4] Added libsoxr detection and optional build of soxr resampler backend.

[Andrey Semashev]

---
 configure.ac| 17 +
 src/Makefile.am |  6 ++
 2 files changed, 23 insertions(+)

diff --git a/configure.ac b/configure.ac
index 26ebd8c..7100c48 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1129,6 +1129,21 @@ AS_IF([test x$with_speex = xyes  test 
x$HAVE_SPEEX = x0],
 AM_CONDITIONAL([HAVE_SPEEX], [test x$HAVE_SPEEX = x1])
 AS_IF([test x$HAVE_SPEEX = x1], AC_DEFINE([HAVE_SPEEX], 1, [Have speex]))
 
+ soxr (optional) 
+
+AC_ARG_WITH([soxr],
+AS_HELP_STRING([--without-soxr],[Omit soxr (resampling)]))
+
+AS_IF([test x$with_soxr != xno],
+[PKG_CHECK_MODULES(LIBSOXR, [ soxr = 0.1.1 ], HAVE_SOXR=1, HAVE_SOXR=0)],
+HAVE_SOXR=0)
+
+AS_IF([test x$with_soxr = xyes  test x$HAVE_SOXR = x0],
+[AC_MSG_ERROR([*** soxr support not found])])
+
+AM_CONDITIONAL([HAVE_SOXR], [test x$HAVE_SOXR = x1])
+AS_IF([test x$HAVE_SOXR = x1], AC_DEFINE([HAVE_SOXR], 1, [Have soxr]))
+
  Xen support (optional) 
 
 AC_ARG_ENABLE([xen],
@@ -1518,6 +1533,7 @@ AS_IF([test x$HAVE_FFTW = x1], ENABLE_FFTW=yes, 
ENABLE_FFTW=no)
 AS_IF([test x$HAVE_ORC = xyes], ENABLE_ORC=yes, ENABLE_ORC=no)
 AS_IF([test x$HAVE_ADRIAN_EC = x1], ENABLE_ADRIAN_EC=yes, 
ENABLE_ADRIAN_EC=no)
 AS_IF([test x$HAVE_SPEEX = x1], ENABLE_SPEEX=yes, ENABLE_SPEEX=no)
+AS_IF([test x$HAVE_SOXR = x1], ENABLE_SOXR=yes, ENABLE_SOXR=no)
 AS_IF([test x$HAVE_WEBRTC = x1], ENABLE_WEBRTC=yes, ENABLE_WEBRTC=no)
 AS_IF([test x$HAVE_TDB = x1], ENABLE_TDB=yes, ENABLE_TDB=no)
 AS_IF([test x$HAVE_GDBM = x1], ENABLE_GDBM=yes, ENABLE_GDBM=no)
@@ -1578,6 +1594,7 @@ echo 
 Enable orc:${ENABLE_ORC}
 Enable Adrian echo canceller:  ${ENABLE_ADRIAN_EC}
 Enable speex (resampler, AEC): ${ENABLE_SPEEX}
+Enable soxr (resampler):   ${ENABLE_SOXR}
 Enable WebRTC echo canceller:  ${ENABLE_WEBRTC}
 Enable gcov coverage:  ${ENABLE_GCOV}
 Enable unit tests: ${ENABLE_TESTS}
diff --git a/src/Makefile.am b/src/Makefile.am
index a4a66c5..b34dae4 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -1012,6 +1012,12 @@ libpulsecore_@PA_MAJORMINOR@_la_CFLAGS += 
$(LIBSPEEX_CFLAGS)
 libpulsecore_@PA_MAJORMINOR@_la_LIBADD += $(LIBSPEEX_LIBS)
 endif
 
+if HAVE_SOXR
+libpulsecore_@PA_MAJORMINOR@_la_SOURCES += pulsecore/resampler/soxr.c
+libpulsecore_@PA_MAJORMINOR@_la_CFLAGS += $(LIBSOXR_CFLAGS)
+libpulsecore_@PA_MAJORMINOR@_la_LIBADD += $(LIBSOXR_LIBS)
+endif
+
 if HAVE_LIBSAMPLERATE
 libpulsecore_@PA_MAJORMINOR@_la_SOURCES += pulsecore/resampler/libsamplerate.c
 libpulsecore_@PA_MAJORMINOR@_la_CFLAGS += $(LIBSAMPLERATE_CFLAGS)
-- 
2.1.0

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

[pulseaudio-discuss] [PATCH 4/4] Added documentation for soxr resampling methods.

[Andrey Semashev]

---
 man/pulse-daemon.conf.5.xml.in | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/man/pulse-daemon.conf.5.xml.in b/man/pulse-daemon.conf.5.xml.in
index 754312e..714e4d8 100644
--- a/man/pulse-daemon.conf.5.xml.in
+++ b/man/pulse-daemon.conf.5.xml.in
@@ -88,7 +88,8 @@ USA.
   optsrc-sinc-medium-quality/opt, optsrc-sinc-fastest/opt,
   optsrc-zero-order-hold/opt, optsrc-linear/opt,
   opttrivial/opt, optspeex-float-N/opt,
-  optspeex-fixed-N/opt, optffmpeg/opt. See the
+  optspeex-fixed-N/opt, optffmpeg/opt, optsoxr-lq/opt,
+  optsoxr-mq/opt, optsoxr-hq/opt, optsoxr-vhq/opt. See the
   documentation of libsamplerate and speex for explanations of the
   different src- and speex- methods, respectively. The method
   opttrivial/opt is the most basic algorithm implemented. If
@@ -98,8 +99,13 @@ USA.
   exist in two flavours: optfixed/opt and optfloat/opt. The former 
uses fixed point
   numbers, the latter relies on floating point numbers. On most
   desktop CPUs the float point resampler is a lot faster, and it
-  also offers slightly better quality. See the output of
-  optdump-resample-methods/opt for a complete list of all
+  also offers slightly better quality. The soxr- family methods
+  are based on libsoxr, a resampler library from SoX sound processing 
utility.
+  The lq variant has the lowest quality, vhq has the best. The Soxr 
resamplers
+  generally offer better quality compared to other resamplers, such as 
speex, and
+  often are less CPU-consuming at comparable or even better quality. The 
downside
+  is that the Soxr resamplers can add a significant delay to the output 
(up to around 20 ms).
+  See the output of optdump-resample-methods/opt for a complete list 
of all
   available resamplers. Defaults to optspeex-float-1/opt. The
   opt--resample-method/opt command line option takes precedence.
   Note that some modules overwrite or allow overwriting of the
-- 
2.1.0

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