[pulseaudio-discuss] Extra A2DP codecs support in bluetooth module

[ValdikSS]

On 22.07.2018 14:37, Pali Rohár wrote:

> 
> Information which I have about FastStream: It is just SBC codec with
> following parameters: frequency rate 44.1 kHz or 48.0 kHz, Blocks 16,
> Sub-bands 8, Joint Stereo, Loudness and Bitpool = 29. So data rate = 212
> kbps, packet size = 72*3+4 = 220 = DM5 and that DSP decoders round 71
> bytes frames to 72 bytes. So I'm not sure how "low latency" it is.
> Normal SBC codec allows you to specify all those parameters. But
> FastStream has one additional feature: it supports backchannel for
> voice, so you do not have to switch between HFP/HSP and A2DP once you
> have incoming voice call. You can always use just A2DP with FastStream.
> 
> Pulseaudio for SBC codec choose those parameters: Joint Stereo, Block
> 16, Sub-bands 8, Loudness. Frequency and bitpool depends on pulseaudio
> source. If bluetooth device does not support those parameters,
> pulseaudio lower values. So for me it looks like that FastStream matches
> default SBC pulseaudio configuration.
> 
> Backchannel in FastStream for microphone voice again uses SBC codec with
> parameters: 16 KHz frequency rate, Blocks 16, Sub-bands 8, Loudness,
> Bitpool 32. So data rate = 72 kbps, packet size = 3*72 + 4 = 220 <= DM5.
> Which should be much better then CVSD codec at 8 kHz used in HFP/HSP.
> But is there really difference for voice data which comes from
> (probably poor) microphone integrated in headsets?
> 
>> handful of Creative headsets that don't seem to support any other codecs. I
>> would put it between SBC and AAC. If someone prefers SBC over it, they know
>> enough about Bluetooth operation to qualify as a power user capable of using
>> the config file to disable FastStream.
> 
> Based on above details I would say it must be similar (or same?) as SBC
> for streaming. But who knows how is receiver implemented? I would not be
> surprised if some bluetooth headset have degraded SBC A2DP codec just
> for marketing purposed to show that other vendor codec is "better".
> 
> As I said, I need to play with FastStream and see what my headset would
> do with it. For me interesting part is that backchannel support to avoid
> all problems with switching between A2DP and HSP/HFP profiles (to
> activate HSP/HFP only in case I have incoming call and after hangup
> switch back to AD2P...).

It would be great if FastStream support could be implemented. I have a headset 
with CSR (now Qualcomm) chip which supports SBC, AptX, AAC and FastStream. The 
headset is rather unknown and not expensive (but surprisingly good), so I 
assume FastStream support is not that rare.
If high-quality duplex audio is possible with Bluetooth, that would be very 
handy for conferences.
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Bluetooth aptX codec

[Arun Raghavan]

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

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

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

I don't get what you mean here.

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

Look at the rtpsbcpay/rtpsbcdepay elements, for example.

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

Re: [pulseaudio-discuss] [PATCH 6/8] message-params: Allow parameter strings to contain escaped curly braces

[Georg Chini]

On 29.07.2018 21:47, Tanu Kaskinen wrote:

On Fri, 2018-07-27 at 10:51 +0200, Georg Chini wrote:

On 27.07.2018 10:08, Tanu Kaskinen wrote:

On Thu, 2018-07-26 at 18:02 +0200, Georg Chini wrote:

On 26.07.2018 12:37, Tanu Kaskinen wrote:

On Sun, 2018-07-22 at 21:11 +0200, Georg Chini wrote:

On 22.07.2018 17:48, Tanu Kaskinen wrote:

On Sun, 2018-07-22 at 16:02 +0200, Georg Chini wrote:

On 21.07.2018 20:17, Tanu Kaskinen wrote:

On Mon, 2018-04-09 at 19:35 +0200, Georg Chini wrote:

+
+/* Read functions */
+
  /* Split the specified string into elements. An element is defined as
   * a sub-string between curly braces. The function is needed to parse
   * the parameters of messages. Each time it is called returns the position
   * of the current element in result and the state pointer is advanced to
- * the next list element.
+ * the next list element. On return, the parameter *is_unpacked indicates
+ * if the string is plain text or contains a sub-list. is_unpacked may
+ * be NULL.

is_unpacked looks like unnecessary complexity.
pa_message_params_read_string() should always unescape the value.

It may be possible, that the string you read is a list. Consider the
following
parameter list: {string1}{some nested structure}{string2}. You can now
read this list as three strings and then continue to read the elements of
the nested structure from the second string. You might even create a
function
that takes a string and outputs a structure. So you are not forced to go
to the full depth of nesting on the first pass. This makes it much easier
to handle deeply nested parameter lists. For me this behavior is an
important
feature and I do not want to drop it. See also my comment on why I do
not always want escaping.

Doesn't split_list() already allow this, why do you want to use
read_string() to do the same thing as split_list()?

read_string() and split_list() are very similar and we could live
without read_string(). It is provided as a counterpart to write_string()
and for convenience additionally does the unescaping if necessary
like write_string does the escaping.
I don't see why this is a problem. It depends on the context which
is the better function to use.

Again, in my mind a structure is not a string, they are different
types, and I think read_string() should only deal with the string type.
is_unpacked makes the API more complicated, so I'd like to get rid of
it.


I don't see your point. is_unpacked is not part of the read_string()
arguments
or return value. In split_list() it is definitively needed to indicate
if the returned
string (in the C sense) contains another list. I can imagine many
situations where
you might either pass an array or just a single value or even NULL.
is_unpacked
allows to differentiate between the situations.

Can you give an example? You say is_unpacked is definitely needed, but
so far the only use case has been read_string(), which you wanted to be
used for reading not only string values but everything else too. If
read_string() is changed to only read string values, then it doesn't
need is_unpacked from split_list().

The parameter types are known beforehand, so i don't see the need for
looking at the data to figure out the type. If introspection support is
desired, then that's a separate project (the is_unpacked flag isn't
sufficient for proper introspection).


This is not about parameter type, it is just to distinguish between
a list and a simple value. One example comes to my mind immediately:
Consider a parameter list that consists of strings and a couple of
arrays. Now you can read this list as an array of strings (patch 8
provides a function for that) and then examine those strings that
contain arrays separately. Having the flag (and using it in read_string())
provides a more flexible and convenient way to parse a parameter list.

The flag may not be strictly necessary at the moment, but I would still
like to keep it.

To continue a familiar theme of my review: if there's a
read_string_array() function, I want that to be used only for string
arrays, not a mishmash of random types. There could be a separate
function split_list_into_array() that does something similar to what you wanted 
to do with read_string_array(). split_list_into_array() wouldn't do special 
string handling, though, so unescaping would be left to the application. I find 
that only logical, since other basic types don't get special handling either 
(i.e. floats aren't converted to C floats).

Your use case could be served with a vararg function that instead of
producing a string array would read into separate variables, like this:

pa_message_params_read(c, state,
PA_TYPE_STRING, ,
PA_TYPE_FLOAT, ,
PA_TYPE_RAW, ,
0);

PA_TYPE_RAW would be useful for reading a list (or anything else) into
a C string without unescaping or other processing. There could be also
PA_TYPE_IGNORE for 

Re: [pulseaudio-discuss] [PATCH 6/8] message-params: Allow parameter strings to contain escaped curly braces

[Tanu Kaskinen]

On Fri, 2018-07-27 at 10:51 +0200, Georg Chini wrote:
> On 27.07.2018 10:08, Tanu Kaskinen wrote:
> > On Thu, 2018-07-26 at 18:02 +0200, Georg Chini wrote:
> > > On 26.07.2018 12:37, Tanu Kaskinen wrote:
> > > > On Sun, 2018-07-22 at 21:11 +0200, Georg Chini wrote:
> > > > > On 22.07.2018 17:48, Tanu Kaskinen wrote:
> > > > > > On Sun, 2018-07-22 at 16:02 +0200, Georg Chini wrote:
> > > > > > > On 21.07.2018 20:17, Tanu Kaskinen wrote:
> > > > > > > > On Mon, 2018-04-09 at 19:35 +0200, Georg Chini wrote:
> > > > > > > > > +
> > > > > > > > > +/* Read functions */
> > > > > > > > > +
> > > > > > > > >  /* Split the specified string into elements. An element 
> > > > > > > > > is defined as
> > > > > > > > >   * a sub-string between curly braces. The function is 
> > > > > > > > > needed to parse
> > > > > > > > >   * the parameters of messages. Each time it is called 
> > > > > > > > > returns the position
> > > > > > > > >   * of the current element in result and the state 
> > > > > > > > > pointer is advanced to
> > > > > > > > > - * the next list element.
> > > > > > > > > + * the next list element. On return, the parameter 
> > > > > > > > > *is_unpacked indicates
> > > > > > > > > + * if the string is plain text or contains a sub-list. 
> > > > > > > > > is_unpacked may
> > > > > > > > > + * be NULL.
> > > > > > > > 
> > > > > > > > is_unpacked looks like unnecessary complexity.
> > > > > > > > pa_message_params_read_string() should always unescape the 
> > > > > > > > value.
> > > > > > > 
> > > > > > > It may be possible, that the string you read is a list. Consider 
> > > > > > > the
> > > > > > > following
> > > > > > > parameter list: {string1}{some nested structure}{string2}. You 
> > > > > > > can now
> > > > > > > read this list as three strings and then continue to read the 
> > > > > > > elements of
> > > > > > > the nested structure from the second string. You might even 
> > > > > > > create a
> > > > > > > function
> > > > > > > that takes a string and outputs a structure. So you are not 
> > > > > > > forced to go
> > > > > > > to the full depth of nesting on the first pass. This makes it 
> > > > > > > much easier
> > > > > > > to handle deeply nested parameter lists. For me this behavior is 
> > > > > > > an
> > > > > > > important
> > > > > > > feature and I do not want to drop it. See also my comment on why 
> > > > > > > I do
> > > > > > > not always want escaping.
> > > > > > 
> > > > > > Doesn't split_list() already allow this, why do you want to use
> > > > > > read_string() to do the same thing as split_list()?
> > > > > 
> > > > > read_string() and split_list() are very similar and we could live
> > > > > without read_string(). It is provided as a counterpart to 
> > > > > write_string()
> > > > > and for convenience additionally does the unescaping if necessary
> > > > > like write_string does the escaping.
> > > > > I don't see why this is a problem. It depends on the context which
> > > > > is the better function to use.
> > > > 
> > > > Again, in my mind a structure is not a string, they are different
> > > > types, and I think read_string() should only deal with the string type.
> > > > is_unpacked makes the API more complicated, so I'd like to get rid of
> > > > it.
> > > > 
> > > 
> > > I don't see your point. is_unpacked is not part of the read_string()
> > > arguments
> > > or return value. In split_list() it is definitively needed to indicate
> > > if the returned
> > > string (in the C sense) contains another list. I can imagine many
> > > situations where
> > > you might either pass an array or just a single value or even NULL.
> > > is_unpacked
> > > allows to differentiate between the situations.
> > 
> > Can you give an example? You say is_unpacked is definitely needed, but
> > so far the only use case has been read_string(), which you wanted to be
> > used for reading not only string values but everything else too. If
> > read_string() is changed to only read string values, then it doesn't
> > need is_unpacked from split_list().
> > 
> > The parameter types are known beforehand, so i don't see the need for
> > looking at the data to figure out the type. If introspection support is
> > desired, then that's a separate project (the is_unpacked flag isn't
> > sufficient for proper introspection).
> > 
> 
> This is not about parameter type, it is just to distinguish between
> a list and a simple value. One example comes to my mind immediately:
> Consider a parameter list that consists of strings and a couple of
> arrays. Now you can read this list as an array of strings (patch 8
> provides a function for that) and then examine those strings that
> contain arrays separately. Having the flag (and using it in read_string())
> provides a more flexible and convenient way to parse a parameter list.
> 
> The flag may not be strictly necessary at the moment, but I would still
> like to keep it.

To continue a familiar theme of my review: if there's a

[pulseaudio-discuss] [ANNOUNCE] paprefs 1.0

[Tanu Kaskinen]

Hello to you. I have something to announce.

The last paprefs release was in 2011, so by now you might have come to
the conclusion that the software had become complete and achieved
perfection. Not so - paprefs is back, now with a version number bigger
than the previous one! But don't make the mistake of thinking that
"1.0" means anything special. It was chosen only because carrying on
releasing 0.9.x releases forever is a bit silly. As we go forward, the
major version number will be incremented whenever new features are
added, and the minor number is incremented when doing pure bugfix
releases (which is the same scheme as what we use with PulseAudio and
pavucontrol).

For users there's not much new stuff: just a new "Send on fixed port
5004" option on the Multicast/RTP tab. Previously the RTP stream was
always transmitted on a random port, which made some use cases
difficult. Oh, and there's also a new Croatian translation.

For packagers the changes are bigger:

 * paprefs now uses GSettings instead of GConf. GConf is unmaintained
software, so distributions are trying to get rid of it. Due to this
change, paprefs now depends on the recently released PulseAudio 12.0
(or newer), or module-gsettings to be more specific. For more
information about how to deal with the GSettings transition, packagers
should read the "The GConf dependency can now be avoided" section in
the PulseAudio 12.0 release notes:
https://www.freedesktop.org/wiki/Software/PulseAudio/Notes/12.0/

 * paprefs was ported from GTK 2 to GTK 3.

 * The build system was switched from Autotools to Meson.

Here's the tarball:
https://freedesktop.org/software/pulseaudio/paprefs/paprefs-1.0.tar.xz
SHA256: ad12e47e2cf120533ffa04e622eb0f255786dfea64f19be5de5a2ba55e8ae778


 git shortlog 

Anders Jonsson (1):
  i18n: update the Swedish translation

Arun Raghavan (1):
  doc: Drop 0pointer.de references

Colin Guthrie (2):
  Do not require a recompile for each new PA version in order to
detect the modules.
  modules: Better code for working out the dynamic module dir.

Felipe Sateler (1):
  Port from GTK2 to GTK3

Jan Tojnar (1):
  Port to meson

NicoHood (1):
  Added fixed port 5004 option for rtp sender

Piotr Drąg (1):
  i18n: update Polish translation

Sylvain Baubeau (1):
  Move from GConf to GSettings

Tanu Kaskinen (18):
  .gitignore: ignore the autogenerated compile script
  build-sys: remove the gconf dependency
  README: remove references to module-gconf
  remove the GSettings schema file
  fix GSettings pkg-config dependency
  remove paprefs.convert
  rename "module" to "module-group" in GSettings schemas and paths
  update the screenshot
  .gitignore: add build
  remove the autotools build system
  README: remove the copyright notice
  README: add "Bug Reports" and "Contributing Code" sections
  README: remove the "Acknowledgements" section
  README: add a news item for the upcoming release
  README: remove reference to an ancient Debian version
  README: clarify the PulseAudio version requirement
  README: remove the page footer
  prepare for releasing 1.0

muzena (1):
  i18n: add Croatian translation

-- 
Tanu

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

Re: [pulseaudio-discuss] Pulseaudio latency

[Georg Chini]

On 29.07.2018 18:03, Georg Chini wrote:

On 29.07.2018 12:44, Harish Gaddameedi wrote:

Hi Georg,

I was working on simple Openwrt Platform, and Source device is 
Android phone Bluetooth with Youtube app 24 hrs live streaming video 
and alsa device is speaker, which is hardwired


The 12 hrs testing which i did on pulseaudio-11.1 are without my 
modification. The basic modification which i made in the previous 
pulseaudio-8.0 is with the idle state of bluez_source card (i.e., 
card is vanishing when the song is in the pause state) and did some 
changes to buffers of pulseaudio to reduce the latency. But in 
pulseaudio-11.1 i didn't do all the changes as i didn't find any 
initial latency. but periodic latency after 12hrs still exists. The 
issue is reproducible with Gstreamer also.


I haven't worked on microphone scenarios, I'm just working on music 
player and speaker.


Let me clear you some test scenarios for better understanding,
Case 1: Android phone as source (bluez_source) and device with 
internal speaker (alsa-sink as sink for pulseaudio) ---> delay 
after 12hrs exists.
Case 2: Device with Gstreamer as source and same device with internal 
speaker (pulsesink with alsa card as sink for pulseaudio) --> 
delay after 12 hrs exists.
Case 3: Device with Gstreamer as source and External Bluetooth 
speaker (pulsesink with bluez_sink card) ---> No delay after 
12 hrs.



What output does module-loopback give when you run with debugging?
Do you see the growing latency there? Does it show up with pactl list 
sinks

or pactl list sources? Any error messages in the PA log?

Regards
 Georg
One more comment: It may well be worth trying 12.2 because the bluetooth 
thread

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

Re: [pulseaudio-discuss] Pulseaudio latency

[Georg Chini]

On 29.07.2018 12:44, Harish Gaddameedi wrote:

Hi Georg,

I was working on simple Openwrt Platform, and Source device is Android 
phone Bluetooth with Youtube app 24 hrs live streaming video and alsa 
device is speaker, which is hardwired


The 12 hrs testing which i did on pulseaudio-11.1 are without my 
modification. The basic modification which i made in the previous 
pulseaudio-8.0 is with the idle state of bluez_source card (i.e., card 
is vanishing when the song is in the pause state) and did some changes 
to buffers of pulseaudio to reduce the latency. But in pulseaudio-11.1 
i didn't do all the changes as i didn't find any initial latency. but 
periodic latency after 12hrs still exists. The issue is reproducible 
with Gstreamer also.


I haven't worked on microphone scenarios, I'm just working on music 
player and speaker.


Let me clear you some test scenarios for better understanding,
Case 1: Android phone as source (bluez_source) and device with 
internal speaker (alsa-sink as sink for pulseaudio) ---> delay 
after 12hrs exists.
Case 2: Device with Gstreamer as source and same device with internal 
speaker (pulsesink with alsa card as sink for pulseaudio) --> 
delay after 12 hrs exists.
Case 3: Device with Gstreamer as source and External Bluetooth speaker 
(pulsesink with bluez_sink card) ---> No delay after 12 hrs.



What output does module-loopback give when you run with debugging?
Do you see the growing latency there? Does it show up with pactl list sinks
or pactl list sources? Any error messages in the PA log?

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

Re: [pulseaudio-discuss] Pulseaudio latency

[Harish Gaddameedi]

 Hi Georg,

I was working on simple Openwrt Platform, and Source device is Android
phone Bluetooth with Youtube app 24 hrs live streaming video and alsa
device is speaker, which is hardwired

The 12 hrs testing which i did on pulseaudio-11.1 are without my
modification. The basic modification which i made in the previous
pulseaudio-8.0 is with the idle state of bluez_source card (i.e., card is
vanishing when the song is in the pause state) and did some changes to
buffers of pulseaudio to reduce the latency. But in pulseaudio-11.1 i
didn't do all the changes as i didn't find any initial latency. but
periodic latency after 12hrs still exists. The issue is reproducible with
Gstreamer also.

I haven't worked on microphone scenarios, I'm just working on music player
and speaker.

Let me clear you some test scenarios for better understanding,
Case 1: Android phone as source (bluez_source) and device with internal
speaker (alsa-sink as sink for pulseaudio) ---> delay after 12hrs
exists.
Case 2: Device with Gstreamer as source and same device with internal
speaker (pulsesink with alsa card as sink for pulseaudio) --> delay
after 12 hrs exists.
Case 3: Device with Gstreamer as source and External Bluetooth speaker
(pulsesink with bluez_sink card) ---> No delay after 12 hrs.



On Sun, Jul 29, 2018 at 3:09 PM Georg Chini  wrote:

> On 28.07.2018 11:20, Harish Gaddameedi wrote:
>
> Dear Georg,
>
> Thanks for reply,
>
> As you have suggested. I have updated the pulseaudio to the later version
> which is after pulseaudio-10.0 (i.e., pulseaudio-11.1). We have found that
> the delay is still exists after playing any music upto 12hrs. We found like
> the audio and video are completely out of sync with a delay of 4-5 seconds.
>
> In the change log between pulseaudio-11.1 and pulseaudio-12.2,  i haven't
> seen any updates regarding latency. I hope that the latency will also be
> exist in pulseaudio-12.2 also.
>
> Thanks,
> Harish Gaddameedi.
>
> On Fri 27 Jul, 2018, 11:20 AM Georg Chini,  wrote:
>
>> On 27.07.2018 07:10, Harish Gaddameedi wrote:
>>
>> I'm working on an Application using pulseaudio package using
>> pulseaudio-8.0, made lot of modifications in the pulseaudio to reduce the
>> fluctuation of source card and to reduce the initial latency, I'm
>> successful in doing this process. On 12 hrs testing of audio with alsa-sink
>> module, I'm finding the latency of 4-5 seconds. When testing the same 12hrs
>> in connection with External bluetooth speaker, there is no latency found.
>>
>> After the 12 hrs testing with alsa-sink, latency from Module-loopback is
>> showing as less than 300ms which is fine. but the latency reproducible is
>> upto 4-5seconds. Can anyone give me a quick pointer if you have faced
>> the similar issue?
>>
>> Thanks,
>> Harish Gaddameedi
>>
>>
>> Hi,
>>
>> I would suggest to update to a newer version of PA. Current version is
>> 12.2.
>> Module-loopback did not control the latency very well prior to 10.0. If
>> you
>> have the same issue with a current PA version, this would need more
>> investigation.
>>
>> Regards
>> Georg
>>
> Hello Harish,
>
> what kind of alsa device are you using on what platform? What did you
> modify
> within PA? Did you try 11.1 without your modifications? What exactly is
> your setup?
>
> If you are talking about A/V synchronization, the player may also be the
> cause of
> the issue. Sound card time does not necessarily match system time, so the
> player
> has to take care of the difference. The bluetooth A2DP sink uses the
> system clock
> for timing, that's probably why you don't have the problem there. Does
> something
> similar happen when you loop back your microphone to the ALSA sink?
>
> I have run module-loopback for days on an Intel platform with standard
> hda-intel
> and USB devices without seeing any delays. Also, in 11.1 there should be
> no need
> to reduce initial latency because module-loopback will adjust quickly to
> the latency
> you requested.
> Regards
>
>  Georg
>


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

Re: [pulseaudio-discuss] Pulseaudio latency

[Georg Chini]

On 28.07.2018 11:20, Harish Gaddameedi wrote:

Dear Georg,

Thanks for reply,

As you have suggested. I have updated the pulseaudio to the later 
version which is after pulseaudio-10.0 (i.e., pulseaudio-11.1). We 
have found that the delay is still exists after playing any music upto 
12hrs. We found like the audio and video are completely out of sync 
with a delay of 4-5 seconds.


In the change log between pulseaudio-11.1 and pulseaudio-12.2,  i 
haven't seen any updates regarding latency. I hope that the latency 
will also be exist in pulseaudio-12.2 also.


Thanks,
Harish Gaddameedi.

On Fri 27 Jul, 2018, 11:20 AM Georg Chini, > wrote:


On 27.07.2018 07:10, Harish Gaddameedi wrote:

I'm working on an Application using pulseaudio package using
pulseaudio-8.0, made lot of modifications in the pulseaudio to
reduce the fluctuation of source card and to reduce the initial
latency, I'm successful in doing this process. On 12 hrs testing
of audio with alsa-sink module, I'm finding the latency of 4-5
seconds. When testing the same 12hrs in connection with External
bluetooth speaker, there is no latency found.

After the 12 hrs testing with alsa-sink, latency from
Module-loopback is showing as less than 300ms which is fine. but
the latency reproducible is upto 4-5seconds. Can anyone give me a
quick pointer if you have faced the similar issue?

Thanks,
Harish Gaddameedi



Hi,

I would suggest to update to a newer version of PA. Current
version is 12.2.
Module-loopback did not control the latency very well prior to
10.0. If you
have the same issue with a current PA version, this would need more
investigation.

Regards
    Georg


Hello Harish,

what kind of alsa device are you using on what platform? What did you modify
within PA? Did you try 11.1 without your modifications? What exactly is 
your setup?


If you are talking about A/V synchronization, the player may also be the 
cause of
the issue. Sound card time does not necessarily match system time, so 
the player
has to take care of the difference. The bluetooth A2DP sink uses the 
system clock
for timing, that's probably why you don't have the problem there. Does 
something

similar happen when you loop back your microphone to the ALSA sink?

I have run module-loopback for days on an Intel platform with standard 
hda-intel
and USB devices without seeing any delays. Also, in 11.1 there should be 
no need
to reduce initial latency because module-loopback will adjust quickly to 
the latency

you requested.

Regards

 Georg

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