from:"pl bossart"

On Thu, Mar 24, 2011 at 8:16 AM, Tanu Kaskinen tanu.kaski...@digia.com wrote:
 Adjusting the sample rate is done in the IO thread, which can cause
 interruptions in the audio if the adjustment requires heavy computation. The
 trivial resampler is guaranteed to be light on the cpu.

 It would be better to adjust the sample rate in some other thread (FWIW,
 module-combine uses the main thread), but this quick hack fixes the immediate
 problem of spending too much time in the IO thread.

I don't think it's the right or only way to solve the problem. If you
are using the loopback and SRC is required, the assumption is that you
don't care too much about latency. If the audio events are spaced
enough, there should be plenty of time to run the resampling. we
should instead adjust the sink/source latencies to reduce the number
of events and not compromize on quality.
This trivial resampler should only be used if for some reason you want
both real-time behavior and low-latency while using an SRC. I fail to
see in what cases you would care? In what practical cases did you
encounter underflows?
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH] loopback: Always use the trivial resampler.

 The sink may be running in a low-latency mode even if the loopback
 stream doesn't have any latency requirements - there may be other
 streams active at the same time with stricter timing requirements.

 FWIW, the practical case here was a very simple test of looping null
 sink's monitor to a hw sink with default settings on Harmattan. It may
 be that our setup is more suspectible to this kind of problems than
 normal systems, but I still think that non-realtime-safe stuff should
 be kept out of the IO threads, regardless of the setup, especially if
 such stuff can very well be done outside the IO thread.

if you are still using 10ms periods on the hw sinks, then yes it's an
artifical use case in a constrained environment that doesn't use
timer-based scheduling...
I don't disagree that doing SRC in an io thread is not that kosher,
but keep in mind that we also do mixing and volume control in the IO
thread. There is some amount of DSP in this thread which will impact
response time to hw events.
Maybe your idea of linking latency with SRC quality makes sense. I
feel however that the speex SRC is not up to snuff and results in high
CPU usage. If we fixed the SRC to use a 'reasonable' MHz figure this
problem would go away.

Loopback is used in Medfield for FM playback only. I haven't heard of
any issues. The only bugs on loopback I've seen are on erratic src
adjustments on BT A2DP and RTP RX, but I haven't tried since Maarten
contributed patches.
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [WIP] Passthrough support

It seems that 384k sample rates aren't supported directly in alsa, I did
some patching to no avail yet.

In any case if the channel count can be specified with passthrough the
following should work.

paplay --raw --channels=2 --rate=192000 --passthrough File.dts.spdif192khz (
this works).

paplay --raw --channels=4 --rate=192000 --passthrough File.dts.spdif384khz (
this fails).

To passthrough dolby true-hd it looks like it'll be necessary for more than
two channels to work.

There was a thread on dts-hd in alsa-devel at some point. Anssi
(cc:ed) contributed some patches for HDMI and provided the information
below on ffmpeg configurations.
You may want to try at the alsa level before trying with pulseaudio to
make sure your setup is correct. I tend to believe you have to go for
8ch @ 192kHz to make this work based on my limited understanding of
HBR.
-Pierre

The DTS-HD part is not merged yet (patch is in ffmpeg-devel@), but the
TrueHD and E-AC-3 support is already there in ffmpeg trunk.

The ffmpeg commandline to use is:
ffmpeg -i input.file -f spdif output.spdif

For DTS-HD files, to get full passthrough (i.e. not only core), a
-dtshd_rate parameter is needed, which sets the output IEC958 rate.
ffmpeg -i input.file -f spdif -dtshd_rate 192000 output.spdif
ffmpeg -i input.file -f spdif -dtshd_rate 768000 output.spdif
192000Hz is enough for streams that have a bitrate below 6.144Mbps, which
means all DTS-HD High Resolution Audio files and even many of the DTS-HD
Master Audio (the latter are lossless VBR).

To play the spdif files back, I use
aplay -D hdmi:CARD=$CARDNAME,DEV=$DEVICENUM,AES0=0x06 -c $CHANCOUNT -r
$RATE file.spdif

- replacing $CARDNAME with the card name
- replacing $DEVICENUM with 0..3 depending on card and hdmi port (for
non-zero DEVICENUM you'll need a patch from alsa git:
http://git.alsa-project.org/?p=alsa-lib.git;a=commitdiff;h=e6d5dcf1f625984605d362338d71162de45a6c60
)
- set $CHANCOUNT and $RATE as per below
- rate 192000 and channels 2 for IEC958 rate 192 kHz (for e.g. 48 kHz
E-AC-3, and DTS-HD when the IEC958 rate was set to 192000 in ffmpeg)
- rate 192000 and channels 8 for IEC958 rate 768 kHz (for most TrueHD
files, and for DTS-HD when the rate was set to 768000)
- note that having the 0x02 bit (non-pcm) set in AES0 is mandatory when
$CHANCOUNT is larger than 2, as ALSA uses it to determine whether to use
HBR or not. The additional 0x04 (non-copyright) I use above is not
mandatory, but is the alsa default so I kept it.
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH] loopback: Always use the trivial resampler.

 It might be that you have misunderstood the reason for the patch. Now
 that I read the patch description again, it indeed isn't entirely clear:
 the problem that I'm having is that the periodic (every 10 seconds)
 reinitialization of the resampler takes too much CPU time. The
 resampling itself is fine - I don't think it's even possible to move
 that out of the IO thread, or if it's possible, it probably wouldn't
 bring any benefits.

ok, makes more sense now. Could it be that this reinitialization isn't
optimized for your platform (Assuming it's Armv7-Neon?)
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] modules/bluetooth/sbc/sbc_primitives.h:41:22: error: expected ':', ',', '; ', '}' or 'attribute' before 'X'

Well you are lucky to even compile, I get a bad dependency with git master.

 CCLD   libbluetooth-ipc.la
make[3]: *** No rule to make target `modules/bluetooth/sbc.c', needed by
`libbluetooth_sbc_la-sbc.lo'.  Stop.

[ume@plb pulseaudio]$ git bisect bad
e4eb4670108ad2b4a0d9c3044e12ed0d933f834e is the first bad commit
commit e4eb4670108ad2b4a0d9c3044e12ed0d933f834e
Author: Luiz Augusto von Dentz luiz.dentz-...@nokia.com
Date:   Mon Mar 14 14:46:10 2011 -0300

build: move sbc related files to its own directory

This should make it easier to apply patches from BlueZ which also uses
sbc subdir for this files.


Went back to before the sbc updates.
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [WIP] Passthrough support

2011-03-15 Thread pl bossart

 I would suggest to use the new API to implement audio passthrough for
 bluetooth devices, it is very likely the we will be disabling unix
 socket IPC in BlueZ. What I would do is, if audio passthrough is
 supported then PA register a mp3 endpoint and try to configure both
 sbc and mp3 simultaneously (only one active at time) when possible so
 we can quickly switch between codecs.

Luiz, what is the time frame for removal of this socket IPC? Will it
still be supported in Meego 1.2, 1.3, etc.? I don't disagree this is
the right thing to do, I am just wondering if we would run into some
integration issues that would actually delay the availability of MP3
passthrough by moving too quickly. Or maybe we can have the two
approaches supported and remove this initial version at a later time?
Thanks,
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [WIP] Passthrough support

2011-03-15 Thread pl bossart

 I pushed your change along with a fix for the assert you saw to my tree
 as well.

I tested the latest batch of patches with AC3/SPDIF this time. Works
well in general, however I found some interesting points:
- in Rhythmbox, the passthrough mode is only enabled if the first file
of playlist is compressed. If you start with PCM/WAV, it always uses
the PCM mode.
- in Totem, the passthrough mode works when the visual effects are
disabled. I see a nice DD on my receiver...However the playback stops
if you play with the volume slider. I get a pop-up error window saying
'an error occurred: pa_stream_set_sink_input_volume(): invalid
argument'

On a related note, maybe we want to change the approach to volume
control. Depending on the sink, there might be ways of using
side/in-band channels to send volume control information to the
decoder. It's going to be protocol-specific. So maybe we need to
provide the client with an information coming from the sink on whether
volume control is actually supported or not.
-Piere
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [WIP] Passthrough support

 I've pushed updates to passthrough-bt branches on my trees for
 pulseaudio (some core changes, rebased to current master),
 gst-plugins-base (MPEG audio payloader), and gst-plugins-good (pulsesink
 MPEG support). With all this, you should be able to test on your BT
 headset.

I've got all these hanges, but still no luck.

[ume@plb GST]$ gst-launch filesrc
location=~/AURAL/Audio/theTest-320.mp3 ! pulsesink
device=bluez_sink.00_0B_E4_94_31_9D
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
ERROR: from element /GstPipeline:pipeline0/GstPulseSink:pulsesink0:
The stream is in the wrong format.
Additional debug info:
gstbaseaudiosink.c(914): gst_base_audio_sink_preroll ():
/GstPipeline:pipeline0/GstPulseSink:pulsesink0:
sink not negotiated.
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
Freeing pipeline ...
[ume@plb GST]$ gst-launch filesrc
location=~/AURAL/Audio/theTest-320.mp3 ! mp3parse ! pulsesink
device=bluez_sink.00_0B_E4_94_31_9D
0:00:00.022098216 30380  0x8add070 ERROR   GST_PIPELINE
./grammar.y:614:gst_parse_perform_link: could not link mpegaudioparse0
to pulsesink0
WARNING: erroneous pipeline: could not link mpegaudioparse0 to pulsesink0

what I am missing in the setup ? PCM playback seems to work fine.
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [WIP] Passthrough support

 There was one bit from pulsesink in gst-plugins-good that I'd missed
 pushing till a couple of hours ago which actually enables MP3 support on
 the pulsesink side. I'm guessing that is missing in your tree?

Nah, I traced the problem to the configure step in gst-plugins-good.
Somehow my version of pulseaudio isn't detected. Not sure what info
the script relies on, it thinks I am based on 0.9.19 when I am using
git master.

I forced support for pulse1.0 it by hand in config.h and found the
same problem with the headset. Trying to figure out the differences
with my initial patches. there must be a step missing.
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [WIP] Passthrough support

 I forced support for pulse1.0 it by hand in config.h and found the
 same problem with the headset. Trying to figure out the differences
 with my initial patches. there must be a step missing.

ok, found a solution, see diff attached. For some reason the
setup_ad2p() did both the SBC and MPEG configuration. Adding a test
for the mode solves the issue, probably there was a buffer overflow or
something bad.

playing with SBC and MPEG works fine now, meaning that the negotiation
works well depending on the payload.
but when I try to go back to PCM/SBC the second time I get the
following assert in pulseaudio (see gst log below)
E: module-bluetooth-device.c: Assertion 'u-write_memchunk.length ==
u-block_size' failed at
modules/bluetooth/module-bluetooth-device.c:1519, function
a2dp_process_render(). Aborting.

I'll let you debug this one, should be easier :-)

Other things I noticed: the volume is much higher in passthrough mode,
maybe we need to find a way to set the volume on the headset to match
the volume used for PCM. Also I heard some high-frequency modulations,
typically coding noise, maybe there's still something fishy during the
mp3 decode part.
-Pierre


[gst-plugins-good]$ gst-launch --gst-debug=pulsesink:5 filesrc
location=~/AURAL/Audio/theTest-320.mp3 ! flump3dec ! pulsesink
device=bluez_sink.00_0B_E4_94_31_9D
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstPulseSinkClock
Got EOS from element pipeline0.
Execution ended after 9540609373 ns.
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...
[gst-plugins-good]$ gst-launch --gst-debug=pulsesink:5 filesrc
location=~/AURAL/Audio/theTest-320.mp3 ! mp3parse ! pulsesink
device=bluez_sink.00_0B_E4_94_31_9D
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstPulseSinkClock
Got EOS from element pipeline0.
Execution ended after 9551288915 ns.
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...
[gst-plugins-good]$ gst-launch --gst-debug=pulsesink:5 filesrc
location=~/AURAL/Audio/theTest-320.mp3 ! flump3dec ! pulsesink
device=bluez_sink.00_0B_E4_94_31_9D
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
ERROR: from element /GstPipeline:pipeline0/GstPulseSink:pulsesink0:
Failed to connect stream: Connection terminated
Additional debug info:
pulsesink.c(1005): gst_pulseringbuffer_acquire ():
/GstPipeline:pipeline0/GstPulseSink:pulsesink0
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
Freeing pipeline ...


diff-arun.patch
Description: Binary data
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [WIP] Passthrough support

 Other things I noticed: the volume is much higher in passthrough mode,
 maybe we need to find a way to set the volume on the headset to match
 the volume used for PCM. Also I heard some high-frequency modulations,
 typically coding noise, maybe there's still something fishy during the
 mp3 decode part.

 I get this sort of thing on, as far as I can tell, one channel as well.
 I figured the decoder on the CSR chip wasn't that great.

Looks to me that the quality is slightly worse than with the initial
patches, but it's of course a very subjective assessment since I need
to reinstall pulse/gstreamer to check the differences instead of doing
an A/B test. Can you check and make sure the payloader doesn't
skip/change any bytes? If you dump what is actually sent to the
headset and compare to the initial file, you shouldn't have any
deltas.
Thanks
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [WIP] Passthrough support

2011-03-12 Thread pl bossart

Hi Arun,
I looked at the passthrough branch. Looks pretty good. I wrote down some notes:

gstaudioiec61937:
- need to check that frame is valid and synchronized on AC3 header
before pushing iec payload
- no code for mp3 and dts?

pulsesink:
- do we really need two steps for payload and commit? Make
things complicated and creates memory copies
- commit needs to prevent toy resampler (maybe this means the sink
cannot work iwth a live source since no adjustment is possible.

-  spec.latency_time = GST_BASE_AUDIO_SINK (psink)-latency_time;
  if (!gst_ring_buffer_parse_caps (spec, caps))
goto out;

Does this work? spec is not initialized?

- change of routing?

- formats
/* FIXME: Eventually, we want the list of supported formats to be set
+ * as properties by the GUI based on what the user says is supported by
+ * the receiver */
+/* FIXME: How do we figure out supported rates? :( */
+unsigned int i, rates[] = { 32000, 44100, 48000 };

For HDMI and SPDIF, 32,44.1 and 48 are mandatory. I think you can
query the alsa layer
to give a range of supported frequencies since this is known in
the driver (either hard-coded or obtained with EDID/eld). I remember
seeing some ALSA patches on this for the NVIDIA cards.

sink.c
- how do we notify client that volume is disabled?

I wasn't too clear on the BT support. You mentioned that it was a
different branch and that it stilll nneds my patches to gst-ugly. We'd
need to have the payloader code in gsraudioiec61937 instead? I am also
not sure how we handle the transition from A2DP w/ SBC to A2DP w/ MP3.
In the current code for iec958, there's no need to reconfigure the
link.

Last, I had 3 conflicts with git master that I had to solve by hand.

Thanks
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Still some SIMD issues

2011-03-12 Thread pl bossart

 When testing with a52, reducing the volume of the Front Centre channel
 to 50% vs. 100% for the others, causes a high pitched artefact to be
 introduced.

 exporting PULSE_NO_SIMD=1 prevents the problem (although I do still seem
 to get some artefacts when mixing - but this could be due to lack of
 rewind on a52 or somehow related to that).

 Just mentioning here by way of recording the issue.

I've had the same issue for ages when playing back multichannel files,
be that on a HDMI or local stereo out. When all the channels have the
same volume everything's fine. When a single channel has a different
setting from the others, there' s this high-frequency pitch. It's been
a year at least but I've never had the time to look into this.
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [WIP] Passthrough support

2011-03-12 Thread pl bossart

Looked at the BT modifications, doesn't look too bad.
I would try first with MP3 support only, so that you don't have
reconfiguration issues. If you support MP3 only from the beginning, it
should be easier to make progress.
If you can work on integrating the payloader in gstaudioiec61937 I
will be able to help you then.
Thanks,
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [WIP] Passthrough support

2011-03-09 Thread pl bossart

 What's here? All the basic plumbing for clients to signal a compresed
 format, have PA pick the best supported one, actually play that
 format, and have pactl list show these. The ALSA sink takes AC3 at the
 moment, and I should be pushing DTS support today/tomorrow after some
 more testing.

I'll give it a try later this week. Thanks!
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH 0/5] Reconfigure sample rates on resume

2011-03-08 Thread pl bossart

 At sink-input trigger a reconfiguration if possible/supported. Sinks
 expose a reconfigure_rate method (I'm sure we can find a better name) if
 they can do a quick switch.

So far it's similar to the update_rate() method I added on the sink,

 In the ALSA sink, this function would check if there are no sink-inputs
 attached and the rate is supported, and then send a message to the I/O
 thread to do the actual reconfiguration. We would cache the rate if
 suspended and apply on unsuspend, or do a suspend-reconfigure-unsuspend
 if it's running.

It's interesting.
The only problems I see is a potential duplication of code, since you
force the suspend in the sink, and it's already part of
module-suspend-on-idle. Meaning you will need to implement this
message in the BT sink as well. I wonder if there would be potential
races if the suspend-on-idle timeout happens right after you enable
the new stream.

 With this, we can replace default-sample-rate with a minimum-sample-rate
 (anything below this gets upsampled), and use the sink-input sample rate
 if supported (or an integer multiple as your code does). The advantage
 of course is that we're no longer restricted to two sample rates.

I don't really see a benefit of having more than 2 sample rates. The
only exception is
passthrough, where you want to forward the sink-input frequency as is.
And reading again I think it's the same behavior I implemented?

 I did a quick walk over the code and this seems feasible. I'm doing
 something similar (but far simpler) for passthrough mode in alsa-sink -
 when a passthrough input is added, I do the
 suspend-update_rate-unsuspend if required and it seems to work fine.

 Does this make sense or am I missing something basic here?

Couldn't you add the same behavior with my patches? If the sink-input
is passthrough then the desired rate is the sink-input rate.
Overall I am still not clear on what your alternative implementation
brings? But I am badly jet-lagged, I may have missed something as
well.
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] pulseaudio xbmc passthrough success

2011-03-06 Thread pl bossart

 I've got pulseaudio xbmc passthrough working.  I've rolled it together with
 a previously windows c++ library called Ac3Filter.  I've been tweeking up
 Ac3Filter quite a bit.  I'm using the Ac3Filter library to Mux spdif.  It
 was a well written library/tools that was relatively easy to get ported to
 linux.

 I'm watching Avatar in wonderful DTS surround sound now.

All you need is a 3D TV now...
Seriously, this is good. Can you send a link to this ported AC3Filter
code? I thought it was too Windows/DirectX-oriented to be used. I
didn't look too much since it's GPL, and LGPL is preferred in terms of
integration with proprietary components.
Thanks,
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] pulseaudio passthrough samplerate

2011-03-03 Thread pl bossart

 It seems that at the moment that if the daemon.conf default-sample-rate is
 set to 44100 then all I can passthrough is 44100 and if it's 48000 all that
 works are 48000 samples.  Is that a limitation in the current pulse
 implementation?

 I expected that this would be set from the pa_sample_spec, but that seems to
 be ignored currently.

 I'm using paplay --rate ? --raw --passthrough for testing.

Yes it's a know limitation I mentioned in my previous emails. Somehow
we will need to reconfigure the passthrough sink frequency.
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [RFC] Alsa UCM integration.

2011-02-25 Thread pl bossart

 Modifiers can be used in the following situations:-

 1) Music is being played. Pulseaudio has configured the Music use case
 verb via UCM. The system wants to play a tone, this could be a beep or
 even a ring tone for an incoming call. Pulseaudio would then check for a
 UCM play tone modifier for the current verb and then enable the
 modifier if it exists. This play tone modifier would setup the
 hardware to play both Music (i.e the verb) and additionally tones (the
 modifier). The modifier may use a different ALSA pcm and hardware volume
 controls to that of the main verb.

 If no play tone modifier exists then Pulsewould mix the tone into the
 music being played in software as it does atm.

 2) Phone call is in progress. Pulseaudio has enabled the phone call UCM
 verb. The user wants to play music on the phone call. The modifier would
 be Music so Pulseaudio will check that a modifier exist for this when
 the phone call verb is active and enable this modifier.

 If no music modifier is available in the phone call verb configuration
 then pulseaudio would mix the music and voice in software.

Make sense.
But I am not sure the profiles as defined today in PulseAudio can work
with modifiers. What we discussed yesterday is that when a profile is
selected then you would set the UCM verb and know about all possible
sinks. We would need additional logic to have profile modifiers, or we
would need extra profiles to represent all possible combinations
(speech, speech+tone, speech+music, etc).
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Virtual Sink Template (was Re: [PATCH 6/6] virtual-sink: Fix a crash when moving the sink to a new master right after setup.)

2011-02-25 Thread pl bossart

 Well, it is a template, but it's also fully functional. The
 functionality is just very limited :)

 If it's not wrong, should the changes there to modargs etc. be migrated
 to the modules which have been spawned from virtual sink?

 I believe there aren't actually any modules yet spawned from the virtual
 sink.

We have internal modules based on the virtual sink. I guess the echo
canceler was also derived from the same concept. And it was based on
the LADSPA sink in the first place.
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [RFC] Alsa UCM integration.

2011-02-25 Thread pl bossart

 the idea was to have at least one card working, so yes this is pretty
 much the same approach than the code in module-alsa-card. Do you have
 any idea on how to manage virtual cards? I'm not clear on they way
 that ALSA manages virtual cards.

I am not clear either. I asked a question on this on alsa-devel, but
the answer from Jaroslav was quite short. I am still unsure how you
actually know when a virtual card is present. I hoped someone could
explain the concept in practical terms, looks like we are all lost
here.
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [RFC] Alsa UCM integration.

2011-02-24 Thread pl bossart

 The initial version of the UCM module is available at the following link:
 http://git.slimlogic.co.uk/cgi-bin/cgit.cgi/pulseaudio.git/log/?h=9.20-ucm_module

 I'm still working in the module, It is work in progress to verify the
 current verb when the stream is closed, also it is needed to add more
 code to work with the profiles and the use cases. Sink, source and
 device data could be taken from the proplist of the verb, and this is
 pending too.

Hi Margarita,
I looked at your patches and have the following comments:
- any reason why your version of PulseAudio is 1.3 years old. The
previous patches on your branch are from 2009-11-18, quite a while
ago. It'll make upstreaming difficult.
- you now have a separate module-alsa-ucm module, but it's called with
a device name as a parameter. So if I have one USB headphone and one
USB mic, this module will be called twice. It's not clear to me then
how the virtual device would be handled, and how this is different
from inserting all the code in module-alsa-card as you did it in your
previous version?
- can you explain why you set the verb using the hook
PA_CORE_HOOK_SINK_INPUT_NEW, with priority PA_HOOK_EARLY+15. There are
other audio-policy related modules that may use different hooks, such
as PA_CORE_HOOK_SINK_INPUT_PUT. I would think you want to set the verb
at the UCM level after all this logic has made decisions, at the last
possible moment before data start flowing.
- how do we make use of modifiers?
- is there a better way to detect that UCM is supported, instead of
having a #define in module-alsa-card.c?

I realize I have more questions than suggestions, this is a good start anyway...
Thanks,
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [RFC] Passthrough support

2011-02-23 Thread pl bossart

On Tue, Feb 22, 2011 at 2:52 PM, Tanu Kaskinen ta...@iki.fi wrote:
 On Wed, 2011-02-23 at 01:00 +0530, Arun Raghavan wrote:
 On Tue, 2011-02-22 at 13:27 -0600, pl bossart wrote:
  ok. Looks good.
  One last comment on proplists. If we don't define a set of mandatory
  elements, then it's going to be really hard to use this
  pa_stream_new_extended() routine. How will the client figure out what
  exactly it needs to send for each format?

 I was thinking that his would basically develop as convention, though
 the few basic properties (rate, channels) could be documented along with
 the pa_encoding_t structure. We can document additional properties (for
 example bitrate, if some sink ever needs it) as being optional but
 recommended if available.

 The set of parameters can potentially grow forever - we don't know what
 parameters may become relevant in the future. So, I think we should
 start by documenting the parameters that we know are important today,
 and define the approach for adding new parameters in the future.

I suggest we first work with known mandatory parameters such as
sampling freq and nb of channels. The connection fails if these
parameters are not set. That's enough to make passthrough work for
now. Future extensions can be worked out later. let's not fall into
academic debates.
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] HDMI passthrough request for help

2011-02-22 Thread pl bossart

 There are a few things missing for me to have xbmc+pulse working well
 with a surround system over HDMI:
 - volume control when in passthrough mode
 - volume control via the amplifier; I see 2 methods here:
        - either via HDMI CEC, but from the latest spec the only
          available commands are volume-up and volume-down, no way
          to directly set a volume, nor to calibrate it properly
        - via a serial cable, it's amp-specific but more capable
 - [off topic] more than 2 PCM channels via HDMI radeon drivers

Does any of these features work with plain ALSA? I don't think what
you describe is a PulseAudio limitation?
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [RFC] Passthrough support

2011-02-22 Thread pl bossart

Hi Arun,

  I've updated this page with the changes discussed so far (and translated
  them into the actual API changes that we need). Please take a look and
  let me know if this looks acceptable.

Couple of comments:
- There is a miss on the pa_format_info. the sampling frequency is
required.  The IEC format can be used at various sampling frequencies.
Passing just IEC isn't enough to configure the link with the receiver.
The number of channels could be 2 by default, but we may need to
change this as well for formats like TrueHD or DTS Master.
- in case no IEC formats are supported by the sink, what is the
returned value? If this is NULL, meaning there is no support, how do
we fall back to plain PCM?
- in case the routing changes, for example if you plug HDMI or BT, how
do we change the connection?

Thanks,
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [RFC] Passthrough support

2011-02-22 Thread pl bossart

 One last comment on proplists. If we don't define a set of mandatory
 elements, then it's going to be really hard to use this
 pa_stream_new_extended() routine. How will the client figure out what
 exactly it needs to send for each format?

 I was thinking that his would basically develop as convention, though
 the few basic properties (rate, channels) could be documented along with
 the pa_encoding_t structure. We can document additional properties (for
 example bitrate, if some sink ever needs it) as being optional but
 recommended if available.

To make things clearer I would add the sampling rate as a mandatory
property in the RFC. the number of channels may be unknown before you
actually decode, and for an IEC format the number of channels seen by
PA is 2...
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] HDMI passthrough request for help

2011-02-18 Thread pl bossart

 First of all I patched pulseaudio git with some updates to treat
 hdmi-passthrough as it does iec958-passthrough.  That seems to work.  I can
 use paplay to pass a dts-wav file through to the receiver and the receiver
 triggers into dts mode and plays it.  A native dts file stripped from and
 mkv movie file on the other hand doesn't play.

 I made some minor changes to the Xbmc pulseaudio driver so that it does not
 ignore passthrough requests.  Xbmc's pulseaudio driver assumes (without
 patching) that passthrough is not available for pulseaudio.  Now I can
 select the pulseaudio passthrough device.  Xbmc has code in it to manipulate
 dts streams.

 The problem is that I can start a movie, Xbmc will select the dts track and
 play, but the receiver doesn't go into dts mode, but instead just buzzes the
 speakers.

Did you actually add the PASSTHROUGH flag when you create the pa_stream?
When the receiver doesn't lock it's typically when the data was
modified by the volume control.
Another possibility is mismatch between frequencies. Make sure the
sink and the stream sampling frequencies match.

Note that we are completely reworking this part, you may want to wait
1-2 months before the feature becomes more stable.
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [RFC] Passthrough support

2011-02-16 Thread pl bossart

  Fair enough. The only niggling API change would be adding a
  PA_FORMAT_PCM_ANY (it would be unwieldy to return one pa_format_info for
  each PCM format).

 I think the PA_SAMPLE_* enumeration should be left alone. Let it be a
 legacy thing for clients that aren't interested in anything else than
 PCM. pa_format_info doesn't need the pa_sample_spec member. The encoding
 type can be provided with a new enumeration with PA_ENCODING_PCM,
 PA_ENCODING_MP3 etc. Then the proplist, or whatever is chosen for
 representing the format set, can contain information saying that
 everything is supported.

 I didn't get the last bit about what you'd add to the proplist. The
 separate enum would work well for the format_info struct, but would you
 also suggest extending the API to use the encoding type while setting
 up/connecting streams?

I agree with Tanu. Changin the PA_SAMPLE_ enum will open a can of
worms since it will create an issue with the byte-to-ms conversion. I
tried in the past and it became a nightmare, I had to change code
everywhere and had to lie on the results. For the passthrough to work,
you want the IEC bistream to look like PCM 16/32 bit stereo so that
these conversions are well handled. You would use a tag/flag/proplist
to make sure the binary data isn't modified/resampled/etc.
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [RFC] Passthrough support

2011-02-16 Thread pl bossart

 - I am not sure I understand how/when the query would be used. Seems
 to me like a notification with the formats exposed by the sink
 currently selected would be more usable. And if a change in routing
 happens (new accessory, audio policy, etc), the client is informed and
 can reconfigure to PCM if need be.

 In this scheme, how would the client first determine what formats are
 available? The notification will also be required - we can either
 piggyback in sink, sink-input and card change notifications, or
 introduce a new one for a change in available formats (I prefer the
 latter).

The problem is that you don't know on what sink you will play until
you have actually created the pa_stream. The audio policy and routing
rules may kick in and if you query before you connect you would end-up
with a broken configuration.
One possibly is to connect as PCM, then get a notification from the
sink that it can actually support compressed data and then configure
the stream.
Another possibility is to connect but ask the sink to provide its
capabilities in return. We would then have another call to refine the
stream configuration.
Maybe we should have a short call on this.
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [RFC] Passthrough support

2011-02-15 Thread pl bossart

 How about reusing gstreamer formats, so that adding a new format to PA
 makes it appear automagically in apps using GST (no need to recompile
 GST) ?

 Tempting as it is ;), we want to keep PA framework-agnostic. Also, in
 most cases, you will likely need to update pulsesink on the GStreamer
 side anyway to do some sort of payloading (IEC 61937 in the formats
 we're talking about now).

Actually Gstreamer would need to add a set of IEC61937 formats as
well. The current IEC968 format exposed in gstreamer can mean either
PCM or compressed but doesn't differentiate between, say, AC3 and DTS.
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [RFC] Passthrough support

2011-02-15 Thread pl bossart

 Please review/comment. Once we have some consensus, I'll send in patches
 to actually get this done.

Thanks Arun,
this is a good start. Couple of comments:
- change raw to PCM, it's less ambiguous.
- I am not sure I understand how/when the query would be used. Seems
to me like a notification with the formats exposed by the sink
currently selected would be more usable. And if a change in routing
happens (new accessory, audio policy, etc), the client is informed and
can reconfigure to PCM if need be.
- I think we need to look at the 'start_move' and 'finish_move' as
well. If a reconfiguration to PCM is needed, we may need to wait until
the client sends PCM again?
- I am not sure the channel map matters for compressed data. The
receiver will adjust anyway to the actual number of speakers, e.g.
downmix if you use a headset.
- you want to add E-AC3 as a basic format. It uses a different IEC syntax
- The receiver may support the same format at different sampling
frequencies (eg MPEG at 32, 44.1 and 48kHz but not any other for BT).
We will need to list explicitly which sampling frequencies are
supported for each format.
- Changing the monitor is tricky, we may want to keep it but either
tag the data as IEC as well, or just zero out.
- On deprecating the PA_SINK_INPUT_PASSTHROUGH: yes it can be removed
as long as you have some means to signal that the data isn't your
ordinary PCM. Extending the pa_sample_spec would break the API, I vote
for a proplist here.

I am sure others will have some remarks as well.
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [RFC] Alsa UCM integration.

2011-02-07 Thread pl bossart

Hi Margarita,

 I've created some code that can read this data out of UCM in module
 alsa-card but I'm now looking for the best way to store this into the
 prop list for the sound card. e.g. should I extend intended roles
 proplist or add new proplist types for UCM.

As I wrote in my comments on alsa-devel, I don't think it's right to
read UCM properties in module-alsa-card. For virtual cards, eg. a USB
headphone and a USB microphone, you will have 2 cards part used for
the same verb. It'd be weird to store UCM values twice. In addition,
somehow we have to reconcile the static list of cards/devices in UCM
configurations with the way PulseAudio detects hardware.

I would think UCM information should be stored in a core proplist by a
standalone module that runs on startup (before module-udev-detect),
and when a card is detected with udev events you can identify in
module-alsa-card which configuration to use. Only then can you set the
UCM verb/devices for that specific card based on the role indicated by
clients.
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [RFC] Dynamic reconfiguration of sampling rate

2011-01-24 Thread pl bossart

 FWIW, the zero-length wait seems to work fine for me as well (also
 HDAudio). A couple of things to consider if we do decide to go ahead
 with this are are that:

Any ideas on how we can make this timeout sink-specific? Everything I
know of (default.pa, module-udev-detect) will set this timeout for all
possible sinks. Not clear to me how I can make this configuratble.
Properties maybe, but I don't know how to set them with a command or
configuration file.

 * We probably need to be more intelligent about resetting the alsa-sink
 smoother since it tends to swing wildly for a while after resume (right
 now it gets reset on every suspend/resume - probably makes more sense to
 only reset if some minimum amount of time has passed)

Good point. Didn't think about that one.
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [RFC] Dynamic reconfiguration of sampling rate

2011-01-21 Thread pl bossart

 I'll do more testing later today. I could see some issues with
 networking or interfaces like S/PDIF or HDMI, where the receiver needs
 to relock. But for local playback we should be fine. You will still

 Not always - anything which doesn't bias the outputs to zero volts (and
 even some things that do) is likely to have some pop/click or delay
 issues on powerup.  Newer hardware will generally do better here but not
 everyone uses the latest shiny.

Agree. I guess if we keep this configurable, the users can decide if
they want to reduce CPU usage/power consumption at the possible
expense of added delays and potential click/pops on the transitions.
It will really depend on usage, hardware support and preferences.
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [RFC] Dynamic reconfiguration of sampling rate

2011-01-19 Thread pl bossart

 I think the general idea was to stop the pops and clicks that would be
 apparent on some devices (maybe some HDA?) when the device is opened and
 closed (and also to be slightly more responsive but that's probably a
 trivial advantage on any machine made this millennium!).

 So I'm not sure we can idle@0s as a general rule, but as I have very
 limited test hardware (namely my laptop and couple other machine which
 aren't really meant for testing!), I can't really say this with any
 degree of confidence.

I'll do more testing later today. I could see some issues with
networking or interfaces like S/PDIF or HDMI, where the receiver needs
to relock. But for local playback we should be fine. You will still
send zeroes out as soon as the sink-input is created, and there'll be
an interval before the first valid sample is provided by the
application.
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] sidetone settings on USB headset

2011-01-19 Thread pl bossart

 In the short term a quick fix may be to do alsactl store 1

That did it. My default sidetone volume is now restored on hot plug
and reboot. I think it's good enough, this is not something that needs
to change on a regular basis. Adding support for sidetone volume in
the GUI would not really make sense. It's simple enough with
alsamixer/alsactl.
Thanks again Colin,
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [RFC] Dynamic reconfiguration of sampling rate

2011-01-18 Thread pl bossart

 Thanks for the work - this was something I was hoping to look at at some
 point. I tried the patches and they do seem to work fine. Will continue
 using them for a bit and see if anything goes awry.

Thanks for the feedback.

 In my normal usage, there is a potential (solvable) problem with this
 approach, though. I use Rhythmbox and most of my songs are at 44100 Hz,
 but there are some at 48000 Hz. If I start playing one of the 48000 Hz
 songs, all subsequent streams will be upsampled to 48000 Hz till I pause
 for 5 seconds.

 As you suggest, this will become less of a problem if we decrease the
 idle time required before suspend, and IMO this enough to make this a
 non-blocker.

I wonder what happens if we set the timeout to zero for ALSA devices?

 Unless I missed something, the only assumption I see in the code is that
 one of the sample rates is a 4000 Hz multiple and the other is a 11025
 Hz multiple, so using, 88200 Hz with an alternate sample rate of 96000
 Hz should also just work.

yes. The idea was to keep SRC complexity under control.

 I see the sink being configured correctly for new sink inputs depending
 on the sample rate of the stream, but reconfiguration to update the
 sample rate of an existing stream on resume doesn't seem to be working.
 I'm testing by running Rhythmbox (not using the xfade backend), playing
 a 48000 Hz song, switching to a 44100 Hz song, pausing for long enough
 to suspend the card and then unpausing. As far as I can tell, the move
 callback isn't called on resume.

That's probably a bug. I didn't try corks/resumes, so it's likely broken.
Thanks again for testing!
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] module-alsa-source latency is 1199291857647 ms

2011-01-18 Thread pl bossart

 My questions:
 1)  The reported latency of 38 years must reflect a bug!(?)  Can this be
 fixed?

This one made my day. Something's obviously broken here. can you
provide the full log for us to figure out what went wrong? with only
some excerpts it's hard to root cause.

 A work-around for the moment is to bypass Pulse by running this command on
 Machine2
 arecord -f S16_LE -c 2 -r 44100 | /usr/bin/esdcat   # Lower latency transmit
 to Machine1

 Using Puleaudio adds 1.5 seconds in the path.

But it also handles clock adjustments between your local rate and
network rate. With your work-around you will have some underrun issues
at some point due to clock drifts.
Thanks,
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [RFC] Dynamic reconfiguration of sampling rate

2011-01-18 Thread pl bossart

 In my normal usage, there is a potential (solvable) problem with this
 approach, though. I use Rhythmbox and most of my songs are at 44100 Hz,
 but there are some at 48000 Hz. If I start playing one of the 48000 Hz
 songs, all subsequent streams will be upsampled to 48000 Hz till I pause
 for 5 seconds.

 As you suggest, this will become less of a problem if we decrease the
 idle time required before suspend, and IMO this enough to make this a
 non-blocker.

 I wonder what happens if we set the timeout to zero for ALSA devices?

Arun, I just tried with load-module module-suspend-on-idle timeout=0,
and it seems to work fine on the HDAudio output. I was able to switch
back and forth between 44.1 and 48kHz tracks without audible issues. I
am not sure what happens with Rhythmbox if you enabled the cross-fade
between tracks, most likely you would remain at the rate defined by
the first song.
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] State of various rate adjustment patches

2011-01-17 Thread pl bossart

 I've tested module-loopback by playing to a null-sink and looping its
 monitor to the real alsa sink. This showed good behaviour, but may be
 the algorithm I used for module-rtp-recv should also be used here.
 Does anyone has a better suggestion for a setup to test
 module-loopback? null-sink and alsa have very stable latencies, so its
 no good test for module-loopback.

To test the loopback, what I had in mind was enabling a BT sink
(receving data from somewhere else using A2DP) and playing locally on
the speakers. That should trigger all kinds of latency issues since
the transmitter essentially pushes packets without worrying too much
about time, and the receiver has to do all the synchronization work.
Should be fairly easy to enable by modifying the
/etc/bluetooth/audio.conf, but I haven't had the time to test so far
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [RFC] Dynamic reconfiguration of sampling rate

2011-01-17 Thread pl bossart

Thanks Colin for reading my prose.

 Yeah, doing it server wide makes no sense IMO. The default-sample-rate
 configure option predates our mixer profile logic and really (IMO)
 somehow be wrapped up into card profiles or sink/source ports anyway,
 but I digress.

That's actually a good point. I just took the existing
default-sample-rate and built on it, but yes there's no reason to have
a server default value. You could have HDMI at 192kHz, no reason to
prevent higher frequencies if they were available.

 - To avoid quality issues, I limited the sinks to two frequencies,
 44.1 or 48kHz. If we allowed for lower sampling rates, it'd be a
 problem if additional sink-inputs/source-outputs are created at a
 later stage with a higher sampling rate. This means that for a phone
 call or voice memo you would still see a resampling, but it should be
 lighter with integer instead of fractional ratios.

 While I see the logic behind it, it'll likely not placate all those
 people who want dynamic rate switching. Perhaps this will need to be
 extended at some point but perhaps it's a sensible starting off point.
 I'm thinking more of even larger frequencies rather than lower ones
 (although the practical usefulness could obviously be debated endlessly)

Humm, I didn't follow your thinking here.

 - the sinks/sources only get suspended after a 5s timeout. This seems
 too high for sinks/sources that can be reconfigured quickly. It may
 make sense to have different values for the timeout, and make them
 dependent on the configuration latency.

 Or perhaps the OK to change rate logic could work when the sink is
 either IDLE || SUSPENDED ? That way the suspend timeout wouldn't really
 matter. Just a thought.

I have more work to do on IDLE. This typically happens when the
sink-input is corked, so you could add an SRC if for some reason the
rate was changed. Even in the SUSPENDED case my USB headset seems to
complain...

 One thing I think would be very interesting here would be cards that
 support hardware mixing.

 With these cards, would it be possible to open a stream for each of the
 different rates we want to use? Then when we deal with the mixing, we
 mix all the like-rated inputs together and send those separately to
 their matched device-stream?

 That is likely the best use of such hardware and the best implementation
 of support for multiple rates, but it's possibly not worth thinking
 about immediately due to the fact that this h/w is likely in a minority.

I can see cases where you have 1 compressed stream and 1 PCM, and you
mix the two in hardware, but I am having a really hard time finding a
use case where you would have multiple (more than 2) PCM streams at
different rates. Maybe automotive cases, where the infotainment unit
might send multiple streams to a head unit were the mixing/routing is
actually done? Did anyone request hardware mixing on the mailing list?
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH] [module-loopback] Add new arguments sink_dont_move and source_dont_move to toggle module automatic unloading when the sink or source were not available

2011-01-03 Thread pl bossart

On Thu, Dec 23, 2010 at 5:40 AM, Cai Yuanqing yuanqing@tieto.com wrote:
    This patch add two new boolean arguments sink_dont_move and
 source_dont_move into module-loopback,so we can make the module unloading
 when the sink or source was unavailable.
 To enable this feature we can do something like:
load-module module-loopback source=bluez_source.00_22_A5_AA_BF_85
 sink=alsa_output.pci-_00_1b.0.analog-stereo source_dont_move=TRUE

 And you can just feel free to ignore these arguments.

I don't have any arguments against the source_dont_move, but I am
concerned about the sink_dont_move part. You may want to listen to
your music on speakers, headsets, HDMI, etc. Why would you restrict
the playback to the sink selected when you loaded the module? I can
see this interfering with the accessory management/audio policy, at
least in Meego. Falling back to the default sink should not add any
noises?
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH 0/3] Fighting rewinds

2010-12-09 Thread pl bossart

 However, the problem is quite complex and there does not seem to be one
 perfect fix, it's more of an optimisation problem. GStreamer in particular
 sends out many small data packages, and PulseAudio does not handle that very
 well.

That's the default behavior, but you can cut the traffic by using the
latency-time property in pulsesink. This makes sure you send bigger
buffers, up to the 64k limit that PulseAudio has internally.
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Supporting hardware resampling

2010-11-29 Thread pl bossart

 Specifically, there is a dedicated DSP on board that can resample,
 multiplex and output audio.  The ALSA driver actually uses this DSP,
 but Pulse Audio is stuck resampling and muxing in user land before
 passing data to the ALSA driver.  I've been browsing around source and
 documentation, and while it seems straightforward enough to create a
 sink module that will dump PCM samples to the DSP, it does not seem
 that this would be sufficient as incoming samples to that sink would
 be resampled to match its parameters.

 Is there some way to make a more generic sink that can take multiple
 sample rates and pass data through?  Is this something that may
 require a card and sink combination instead of just a sink?  Or maybe
 I should just ask is this possible without major changes in Pulse
 Audio's architecture?

Default PulseAudio behavior is to mix in software. If you wanted to
mix in hardware, you could highjack the passthrough work I've been
doing for AC3. Essentially one device for sw mix, and a number of hw
devices with no processing in PulseAudio. Still fairly hairy stuff at
this point since you need to tag each stream as passthrough or not,
and route explicitely to a specific device for hw or sw mixing. You
would also need to load these devices by hand in the default.pa
configuration or use a specific profile for your hardware.
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Latency control for wine ALSA emulation?

2010-11-29 Thread pl bossart

 I'd rather not hardcode tsched=0 because I'm on a laptop =). Please let
 me know what other things I can do to debug, would a log be helpful
 (since the issue is pretty certainly the latency control), or should I
 get a wine log instead. That would probably be a waste of time since
 winealsa isn't maintained currently I believe.

if you want to use tsched, can you experiment with a buffer size that
works for you? module-alsa-sink can take the following parameter:
tsched_buffer_size=buffer size when using timer based scheduling 
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] dynamically changing alsa sink/source sampling rate

2010-11-15 Thread pl bossart

 I wont say it will never be supported (if someone writes a well formed
 patch that doesn't introduce any significant complications/overhead then
 I can't see any problems with merging it), but I doubt any of the main
 developers or companies supporting PA will want to do this any time soon
 (although I could of course be wrong here).

It's on my radar, this is a change that is required for compressed
data support, and while we are at it we could modify the behavior for
PCM as well. Jyri seemed in favor of this as well on the Nokia side.
What I had in mind is that changes in sampling rates would be allowed
only if a sink/source is inactive and the actual hw device closed, and
only if the application has a role where such a change makes sense.
That would enable low-power use cases without requiring resampling.
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] dynamically changing alsa sink/source sampling rate

2010-11-15 Thread pl bossart

 I think that would solve the (or my) most common use-case (imho):

 play music (usually 44100hz)
 stop music
 play movie (usually 48000hz)
 stop movie
 (rinse and repeat)

Yeah, I am only talking about 44.1 and 48 changes. All the other
frequencies can be resampled fairly easily.
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH] bluetooth: MP3 passthrough over A2DP

2010-11-08 Thread pl bossart

Thanks for the reviews. I will resubmit the patch later this week.
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH] bluetooth: MP3 passthrough over A2DP

2010-11-07 Thread pl bossart

Thanks Tanu,
couple of comments on your review:
- I did spent a lot of time correcting these spaces, but there's
always some that go through. If anyone had a indent configuration,
it'd be simpler to review patches having the same style... That's what
gstreamer does. I'' fix those by hand but it's a pain.

 Should this be put a few lines earlier, before if (codec-configured 
 seid == 0)? If we return codec-seid, this function will be called
 again once, but is it possible that also the second invocation will
 return codec-seid? If it's possible, then u-a2dp.has_mpeg is left as
 FALSE, which is probably wrong.

No the code is called twice and the second time with an seid different
from zero. Only when the second call succeeds do you want to record
this endpoint as a valid one.

 +            pa_log(setup_a2dp: Trying to set-up A2DP Passthrough 
 configuration but no MPEG endpoint available);
 +            return -1; /* this should not happen */

 Please use assertions for stuff that should not happen. That makes it
 much easier to reason about the code - if there's no assertion, the
 reader has to assume that it actually is possible that this code is
 executed in some situation, and if the reader wants to know what
 situation that would be, it may take a significant amount of work to
 figure out that in the end the code can not really be ever executed. The
 assertion is a promise that somebody else has already done that
 checking. Having just a this should not happen comment looks like the
 author of the code isn't quite sure whether proper error handling is
 required or not.

I guess the comment is wrong. no need for an assert.

 Time to revisit the sample vs frame discussion... I'm sorry I never
 replied to your last mail concerning this. I'll reply now.

 You wrote:
 It's actually number of samples. Frames only makes sense for PCM, for
 compressed data what you need is the number of samples. Frames are
 undefined for compressed data.

 I'm fairly sure pcm frame means something else to you than to me. If
 the sampling rate of a pcm stream is 48000 Hz and the stream has two
 channels, then one second of that stream contains 48000 pcm frames and
 96000 samples when using my definition of terms pcm frame and
 sample. I guess you would say that one second of such stream contains
 48000 samples and some smaller number of pcm frames - I don't have an
 idea what the definition of pcm frame would be in this case.

- on the samples/frames discussion, this is just a matter of wording.
People with a DSP background will use samples because that's a concept
they can relate to. There's no such thing as a framing frequency...
Frames are used by people with a CS background who don't understand
what the sampling theorem is.


 There already are functions pa_sample_size() and pa_frame_size() that
 follow the terminology I'm advocating. The audio APIs that I'm familiar
 with use the same terminology: alsa has types called snd_pcm_uframes_t
 and snd_pcm_sframes_t and jack has jack_nframes_t.

That's valid for PCM only.

 It's possible that there was no misunderstaning, and you're really
 claiming that compressed data doesn't care about pcm frames, but I very
 much doubt that...

 So, how about renaming this array to pcm_frames_per_mpeg_frame?

If that makes you happy I'll do the change, but this is clearly a
wrong interpretation. You want to infer the length of a frame in ms by
dividing the sampling rate by the number of sample points...


 Fix spaces. Also, you use constant index 1 - that's wrong for  32kHz
 streams, isn't it?

I have to check this one, can't remember why this was done this way.

 +        if (preambles == 0x72F81F4E) { /* little endian assumed *

 Where is this magic number specified? What document should I read in
 order to understand and verify this code?

IEC958 standard.
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Add a new target to Pulseaudio log feature

2010-11-05 Thread pl bossart

  I would like to add in the log feature of PA a way to log(redirect)
 ‘pa_log_*’ messages in a file, which can be a char device for ex. That means
 adding a target to the log of pulseaudio. This target is not settable yet
 and I made changes in Pulseaudio for enabling a new log target of file type.

Can't you just configure the setting below in client.conf?
; extra-arguments = --log-target=syslog

-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [RFC] disabling monitor source patch

2010-11-04 Thread pl bossart

 As part of the passthrough/compressed data support in PulseAudio, we
 need to disable monitoring. The main use of monitoring is to build
 peakmeters to show volume information, and that just doesn't make
 sense for compressed raw data

 I have also been using it several times to record things as streaming music,
 skype conversations etc. So I would say that the peak meters are not the
 only main usage of monitoring.

 Also, we always have a sink and a source, because of module-auto-sink that
 adds a null sink (and a monitor of that) if no sinks exists. If we end up
 having no sources at all, would that open up a can of worms?

 I would say to go with keeping the monitoring source - either decode it,
 leave the raw data as it is, or write zeroes, whatever we conclude is the
 best way to go.

Just to be clear, what I am proposing is to disable monitoring sources
only for the case where a sink supports compressed data. Null sink
doesn't so there's no change of functionality.
You could push silence instead, but that's a pretty much a waste of
resources; I don't see any need for monitoring for compressed data at
all for a pass-through mode... If you need to decode, it has to be
done upstream.
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

[pulseaudio-discuss] [RFC] disabling monitor source patch

2010-11-03 Thread pl bossart

Hi,
As part of the passthrough/compressed data support in PulseAudio, we
need to disable monitoring. The main use of monitoring is to build
peakmeters to show volume information, and that just doesn't make
sense for compressed raw data
I started disabling the monitor sources, but I found out some isses
with the specific modules (dbus interface, http protocol, rygel
server), where I could use some help. I have no idea what these pieces
of code do and what the behavior should be if there is no monitor
source for a specific sink. These isssues are highlighted with FIXME
in the code.
Thanks for your feedback,
-Pierre


disable-monitoring.patch
Description: Binary data
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Routing of audio to loudspeakers or headphones

2010-11-01 Thread pl bossart

 For jack sensing, we'd need a module that traps input events. ALSA
 sends an input event when the headphone jack is inserted. This is
 what's used in Meego (the detection isn't part of PulseAudio though).
 You could then add enable the effect.
 -Pierre

 Could you tell me where (in which source code file) I can find this detection 
 in
 Meego?

It's part of the Ohm plugins.
http://meego.gitorious.org/maemo-multimedia/ohm-plugins-misc/blobs/master/plugins/accessories/wired.c

I am not sure this code is current, someone from Nokia would need to
comment But you'll see all kinds of jack detection in there.
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Does PA have sound effects like SRS Sorrounding, 3D Spatializer, sound enviorment emulation etc?

2010-10-28 Thread pl bossart

        Does anybody know that if PA has sound effects like SRS Sorrounding, 
 3D Spatializer, sound enviorment emulation etc?

        Or is there any above sound effects solution under Linux?

PulseAudio has support for LADSPA, you can plug effects of your
choice. Check out http://www.ladspa.org/
There are some limitations as the effects are applied after mixing, I
am not sure you can apply a per-stream effect before mixing.
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] New dependency: Orc

2010-10-27 Thread pl bossart

 I've been doing some work optimising the software volume scaling code,
 and along with my previous changes to decrease the maximum volume to
 2^31-1, there seems to be a pretty good performance increase (almost 2x
 on my Core2 processor).

Are you saying you have a 2x performance gain over sse assembly? That
would most likely mean we need to fix the assembly for x86 and have an
even better performance than with orc and its intermediate step of
SIMD code generation...
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH] volume: Fix incorrect usage of PA_VOLUME_IS_VALID

2010-10-19 Thread pl bossart

On Tue, Oct 19, 2010 at 3:56 AM, Colin Guthrie gm...@colin.guthr.ie wrote:
 'Twas brillig, and Arun Raghavan at 19/10/10 08:33 did gyre and gimble:
 The commit that introduced this macro was incorrect in some places. This
 patch fixes these. Thanks to Pierre-Louis Bossart for pointing this out.

 I thought I'd looked over all the cases where this was used to spot
 these as I was mindful that this could have been a problem easily
 introduced with this kind of change, but clearly I didn't do a good job.
 So much for that :s

 I've pushed this patch now as it's very obvious from looking at the
 changes that it's needed.

 Would be good if it did solve all of Pierre's issues too.

This patch corrects the issue I reported. Thanks Arun.
However I am now having problems with my multichannel files even when
the same volume is applied for all tracks constant high frequency
noise...more git bisect ahead of me...
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

[pulseaudio-discuss] Noise when setting volume of individual tracks w/ multichannel files

2010-10-18 Thread pl bossart

Hi,
I tried to see if the latest changes in git master to the volume
control code fixed a bug I noticed some time ago. No luck. When
playing a 6-ch file, if I change the volume of, say, the front left
with pavucontrol, a noise appears. As soon as one volume setting is
different (higher or lower) from that of the other channels I hear
this noise. If the volume changes for all channels at once, the noise
disappears.
I don't really understand the volume control code, but I wonder if
this can be confirmed by others?
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

[pulseaudio-discuss] Broken volume control

2010-10-18 Thread pl bossart

Looks like the volume control logic has taken a big hit, when I move
the volume up and down with the slider on the Output Devices tab in
pavucontrol, I have _huge_ pops and clicks, the volume goes to zero in
the playback tab.

Git bisect flags the following patch and I manually confirmed that
this patch introduces the noises. Arun, can you look into this? I
noticed that there are some inconsistencies on the use of
!PA_VOLUME_IS_VALID, sometimes the ! is missing.
Thanks,
-Pierre

$ git bisect bad
49101fc540aec9a249e97a9f650be38f9f92f5ac is the first bad commit
commit 49101fc540aec9a249e97a9f650be38f9f92f5ac
Author: Arun Raghavan arun.ragha...@collabora.co.uk
Date:   Sat Oct 9 15:38:43 2010 +0530

volume: Clamp volume to PA_VOLUME_MAX

This ensures that we always clamp the volume to PA_VOLUME_MAX. While
this currently has no effect, it will be required for making sure we
don't exceed PA_VOLUME_MAX when its value changes in the future.
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH] AC3 passthrough support

2010-10-14 Thread pl bossart

  To use this feature from other frameworks (gstreamer, etc), we will
  need a tagged release to #ifdef code related to AC3 passthough for
  backwards compatibility. Any idea when that might happen?
  (would also be nice to close the gap between git master and meego
  versions while we are at it...)


 What's the status on this? Is it usable and #ifdef able? This would be damn 
 good
 news for us (xbmc).

I am planning some changes to the existing patch. The current solution
only uses a 'passthrough' flag, but you would need additional
information to pass format information so that you can pass MP3 to
play over BT headset, or AC3 over HDMI. Today this isn't possible with
a boolean only.
I am not familiar at al with XBMC, if you have specific requirements
or ideas, they are welcome at this point. I only looked at the problem
from a gstreamer perspective. The main idea so far is to try and use
the passthrough mode, and if the connection fails (no support in
hardware or audio policy), then you would fall back to software
decode.
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [RFC - MP3 passthrough over A2DP 1/2] mp3 passthrough: core changes

2010-10-14 Thread pl bossart

 There's no real way you can extract timing information just by looking
 at the data. You either need to parse the frames (what I did for the
 BT work) or  let the hardware report the number of samples it decoded
 and rendered. In both cases, you could find out what the average bit
 rate is and have an approximate idea of the relationship between the
 numbers of bytes passed to pulseaudio and the duration. It would be a
 bad idea though to rely on this approximated bitrate to infer timing.
 The client should get the audio time as reported by this sample count,
 not through inversion of an approximation that will only be correct
 for constant bit rates. Instead of basing all time ports on
 GET_LATENCY messages we should really have a new GET_TIME message.

 Why can't the encoded data for MP3 be handled the same way as DTS/AC3 over
 spdif/hdmi? They are preformatted with a iec958 header and padded with zeroes 
 to
 the correct sample length given samplerate and channel count.

 To padding and adding of this header is up to the application. Now if a2dp
 supports mp3 as a raw format can't the a2dp code in bluez or whatever is
 communicating with the a2dp device strip the header.

 This way timing through pulse remains simple..

That's exactly my plan. I experimented with raw frames and it turned
out to require too many changes. So yes the Mp3 stream would be
reformatted as an IEC61937 format, and the pulseaudio sink would
indeed strip the additional header and padding.
The issue is that you can have different IEC61937 formats, and I would
like to have additional information passed rather than the existing
'passthrough' flag. This is mainly need to make sure you link a
sink_input with a sink that supports the relevant format.
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [RFC - MP3 passthrough over A2DP 2/2] mp3 passthrough: Bluetooth changes

2010-10-06 Thread pl bossart

Thanks Tanu for your review. Here are some replies on the comments not
related to formatting. There's a nice idea on passing frame-aligned
data in memchunks that looks interesting, this is valuable feedback.
-Pierre

+ uint64_t s_read_index, s_write_index; /* count in samples instead of
bytes */

The unit seems to be actually pcm frames, not samples.

It's actually number of samples. Frames only makes sense for PCM, for
compressed data what you need is the number of samples. Frames are
undefined for compressed data.

+ codec = (codec_capabilities_t *) rsp-data; /** ALIGNMENT? **/

codec_capabilities_t contains only 8-bit variables, which to my
understanding guarantees that it doesn't matter where the data happens
to be located in the memory. If you agree (I don't consider myself an
alignment expert), then I suggest you remove the ALIGNMENT? comment
from here and from parse_caps.

This is code I copy/pasted from the existing code...No idea if there's
a problem here.

+ u-a2dp.has_mpeg = has_mpeg;

As far as I can see, the local has_mpeg variable is redundant; you can
use u-a2dp.has_mpeg = TRUE here.

Right

+ /* vbr - we always say its vbr, we don't have how to know it */
+ mcap-bitrate = 0x8000;

I'm not sure what we don't have how to know it tries to say.

This is taken from the mpapay element in gstreamer. What this is
saying is that bitrate doesn't really matter.

Also, does every BT device that supports MP3 support VBR?

They should. This is indicated in the endpoint capabilities. I don't
have any headset that doesn't support all valid rates.

+ pa_log(setup_a2dp: Trying to set-up A2DP Passthrough
configuration but no MPEG endpoint available);
+ return -1; /* this should not happen */

If it happens anyway, can the bug be anywhere else than in Pulseaudio's
code? If not, use an assertion.

No, in that case the profile is not loaded.

+
+ /* FIXME : number of samples per packet */
+ u-samples_per_block = 1152;

So is this assuming certain link_mtu and certain constant (or average)
bitrate? Since the samples per block ratio doesn't stay constant with
vbr streams, is this variable going to become unneeded when you
implement the timing logic correctly?

The issue is more that the mp3 frame is 576 samples below 32kHz, and
1152 above. This was the meaning of my comment.

+static int a2dp_passthrough_process_render(struct userdata *u) {

I think you should add Run from IO thread comment here. I know
a2dp_process_render() doesn't have the comment either, but I think it
should.

Right

+ /* inits for output buffer */
+ a2dp_prepare_buffer(u);

Not really related to this patch, but I checked a2dp_prepare_buffer
implementation, and it seemed broken: it sometimes calls pa_xmalloc()
from the IO thread. Fixing that doesn't belong this patch, though. I
just thought I'd mention. Someone should fix that, but it's a completely
separate task, so there's no reason that someone should be you...

yes, I also didn't understand why the buffer is 2x larger than needed.

I suggest you do the parsing of the mp3 frames as soon as possible, i.e.
in pa_stream_write(), and drop the data that you can't parse
immediately. That way there will never be gaps when the data is
processed in the server (the server must still not crash if such gaps
are found, in case the client is using something else than libpulse to
communicate with the server).

I also suggest that you make sure that memchunks contain only whole
frames. That way it's always possible to map a memchunk's data to time,
and also map a memblockq's data to time. I would guess that those
mappings will be needed.

It's assumed that some level of parsing is done before going into
pulseaudio (such as mp3parse in gstreamer). I initially through I
would only pass bytes through the pa_stream interface. But maybe you
are right, passing frame-aligned binary data with additional fields
such as type and length would make my life simpler. This is an
interesting idea, let me think about it. That could avoid some of the
timing issues and API breakage we are facing otherwise.

+ header-m = talk_spurt;

talk_spurt is a redundant variable. You can use simply header-m = 1
here.

Yes. I used to set this variable only when a first sync word was
found, as explained in the RTP spec, but apparently it's set to one
all the time in the mpapay implementation.

+ header-sequence_number = htons(a2dp-seq_num++);
+ header-ssrc = htonl(1); /* should in theory be random */

Why should it? And why is it not? What are the consequences of this
choice?

In the RTP spec, it is recommended that the ssrc be random for each
session for additional security. In the BT case, this is really not
that important.

if (audio_sent = time_passed) {
pa_usec_t audio_to_send = time_passed - audio_sent;

/* Never try to

Re: [pulseaudio-discuss] 61ms delay in pa_simple_write()

2010-09-24 Thread pl bossart

Hi Fengguang,

 Hmm it seems there are zero memory allocation delays, so it's at least
 not the root cause of the qemu delays in my case.

Can you run a sanity check with the tsched=0 option at the end of the
module-udev-detect line in your /usr/etc/default.pa file? This will
disable the use of timers and instead use the ALSA period events to
wake-up the real-time thread. PulseAudio will then behave as a
traditional ALSA front-end. If this works, then it means the logic
behind the timer-based scheduling fails in your system.
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] 61ms delay in pa_simple_write()

2010-09-24 Thread pl bossart

 For normal alsa playback, their typical values are 1024.  Pulseaudio
 sets them to large values and maybe is not entirely depending on the
 poll. It may be setting some timer to wake up itself when the DMA
 buffer runs low on data.

 Anyway the pulseaudio's large buffer scheme makes possible the 61ms
 pa_simple_write(). Qemu is not expecting such a large latency. Its
 QEMU_PA_SAMPLES defaults to 1024, which can only hold up to
 1024/48=21ms samples. So the 61ms delay will obviously overflow the
 data push based USB audio model..

The default PulseAudio configuration is 4 periods of 25 ms each. You
can reduce this if you want by changing the relevant fields in
/usr/etc/daemon.conf
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH] BlueZ Media API

2010-09-24 Thread pl bossart

 Note: This probably conflicts with Bossart's patches so we probably need to
 rebase once we find out which one should get in first.

My patches are not in a state where they can be merged in git master.
You go first...
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [RFC - MP3 passthrough over A2DP 1/2] mp3 passthrough: core changes

2010-09-23 Thread pl bossart

 I fully agree, except that I don't understand what's wrong with
 GET_LATENCY. AFAIK, GET_LATENCY returns the time that it will take for
 the next sample that enters the system to get out of the speakers. How
 would GET_TIME differ from GET_LATENCY, and why would it be better?

GET_LATENCY finds out how many bytes are currently buffered, and once
you subtract this from the number of bytes sent to PulseAudio you get
the number of bytes played. Dividing by the sample size gives you the
audio time.
A GET_TIME message would fetch the sample count straight from the
sink, no matter how much was buffered, and no matter what type of data
you handle you can convert to a time value if you divide by the
sampling frequency. If there's no mixing the two messages are
equivalent for PCM data.
Cheers,
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

[pulseaudio-discuss] [RFC] stream API extensions to support compressed data

2010-09-23 Thread pl bossart

Here's a first proposal that I think avoids major disruption in the
development. Two new routines are added to specify the pa_stream will
transport non PCM data. This new extended type will be passed through
the native protocol instead of the 'passthrough' flag I added earlier,
and all sinks/sink-inputs/sources/source-outputs on the server side
will make use of this extended representation.
It'd be nice to have a means to query what the sink capabilities are
before creating a stream with a non-PCM type, but you don't know on
what sink you will play until you actually connect and server-side
heuristics/audio policy kick-in. The expected behavior on the client
side is that if the connect_playback call fails with compressed data,
the application will have to reconfigure its pipeline to provide PCM
data and retry.
The simple API remains simple and handles PCM only.
Feedback welcome
-Pierre


stream-api.patch
Description: Binary data
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [RFC - MP3 passthrough over A2DP 1/2] mp3 passthrough: core changes

2010-09-22 Thread pl bossart

 Again, unless there's a good reason not to, I'd put
 pa_assert(spec-format != PA_MP3) here.

 If the plan is to add other codec support longer term, then perhaps a
 function is better?

 e.g.

 pa_assert(!pa_format_is_compressed(spec-format));

 That way others can be added more easily in the future?
 (not sure if this is a concern or if PA_MP3 would be better named as
 PA_ENCODED_DATA, but my guess is that some kind of timing information
 will eventually be extracted from MP3 streams to control processor wake
 up/sleep times etc, and thus individual encoding systems would have to
 be identified separately as is currently with PA_MP3)

That was one of the points I listed. If we start adding support for
AC3, DTS, MP3, AAC, we will never cease updating these files. I would
be better to signal that the format is ENCODED, meaning all the bytes
to usec conversions used for PCM do not apply, and have a second
structure that would list the type and possibly contain some
parameters required by the decoder.
It looks like my main patch was not published since it's slightly over
the size limit. I did make a lot of changes in the
module-bluetooth-device code, not sure how I can break those in
pieces. Does anyone have admin rights to let it through?
Thanks.
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [RFC - MP3 passthrough over A2DP 1/2] mp3 passthrough: core changes

2010-09-22 Thread pl bossart

 Annoyingly, no I don't have list rights... I asked a while ago, but no
 reply :(

Oh well, I will rework the patch and repost it in a couple of days...

 It was my understanding that Lennart wanted to have some way to extract
 timeing infromation from compressed codecs etc. to allow for wakeup
 times to be calculated properly. I'm not sure if the usec conversions
 need some kind of supplement for compressed formats? I suspect however
 if timing information is to be extracted successfully from these
 formats, we'd need to know which format it actually is.

 Your suggestion seems reasonable, but not sure it can be used without
 API breakage (e.g. the extra subtype information?). I've not really
 looked to closely so this may not be an issue at all.

There's no real way you can extract timing information just by looking
at the data. You either need to parse the frames (what I did for the
BT work) or  let the hardware report the number of samples it decoded
and rendered. In both cases, you could find out what the average bit
rate is and have an approximate idea of the relationship between the
numbers of bytes passed to pulseaudio and the duration. It would be a
bad idea though to rely on this approximated bitrate to infer timing.
The client should get the audio time as reported by this sample count,
not through inversion of an approximation that will only be correct
for constant bit rates. Instead of basing all time ports on
GET_LATENCY messages we should really have a new GET_TIME message.

In terms of API changes, for the passthrough work I managed to avoid
any breakage with an additional flag. I think if we change the
pa_sample_t and add new fields, we will break everything. Maybe we can
change the API in a backwards compatible mode, where we use a
pa_sample_extended_t if this flag is set. The native protocol would
need to change no matter what, but if this is hidden in libpulse we
should be good, right?

Cheers,
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH] Do not use tsched watermark if tsched is disabled

2010-09-07 Thread pl bossart

 So what does this test mean? pavucontrol obviously affects the latency
 of the sink due to it's VI meters. This obviously increases the
 likelihood of a rewind being triggered.So, with this in mind what
 values do you suggest we pick?

 Pierre, is it your understanding that it is when DMA transfer collides with
 cpu-RAM transfer that makes the DMA stream to become broken permanently? Or
 exactly what is it that makes it break?

The low-latency setting has nothing to do with rewinds. It's when you
actually change the volume that you will rewind and remix with the new
stream volume. You could set a super low latency and rewind exactly
once when the stream starts.

There are two issues with the rewind. One is a race condition between
the DMA and the ring buffer update. If you rewind and update the ring
buffer, the DMA may actually have already fetched older data. The
second is that you could experience underflows if you don't do the
update fast enough. By enabling logs you should be able to find out if
there are real underflows.
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH] Do not use tsched watermark if tsched is disabled

2010-09-02 Thread pl bossart

 Agreed: You can pick those two patches, and then we add a third patch to
 both branches, which brings back the watermark for tsched devices and 20
 ms for non-tsched. Assuming my suspicion is not disproved, of course.
 What does Pierre think of that?

I don't want the watermark to be used for rewinds. The watermark is
there for timer-based scheduling, so that you have enough time to
wake-up from sleep and still refill the buffer.
The rewinds happens when the processor is already awake, pulseaudio up
and running and only the remix part needs to happen. Plus the
watermark varies and the logic could really be improved.

Also I think 20ms for rewinds is way too much. This will kill your
actual latency. Imagine you have a low-latency app that starts, the
first sample would be heard after at best 20ms. Not acceptable for
speech or interactive sounds.

But I agree that 256-bytes isn't fool-proof for heavy duty use cases
such 8ch 192kHz 32-bit float.

So how about we keep 256 bytes (1.33 ms for 48kHz) but add a 1.33 ms
threshold to make sure we never rewind below.

rewind_safeguard = max(256, pa_usec_to_bytes(1330));

This way you solve both the hardware issue (frequency independent) and
leave enough headroom for the system to avoid underflows.
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH] Do not use tsched watermark if tsched is disabled

2010-09-01 Thread pl bossart

 Probably either one will work, but if we're about to release 0.9.22
 (heard something from Lennart yet?), I suggest we go with my version for
 0.9.22 as that one is the least invasive (only touches non-tsched
 devices), and keep Pierre's version in master.

 Sounds reasonable. Pierre, what's your take?

That would mean an additional post-release patch for tsched devices. I
am lazy and would prefer a one-stop fix. I don't care if this is
David's or mine, as long as the solution works for both cases.
The only real difference is the bytes/ms parameter. Although ms are
more intuitive, the bytes makes more sense from a hardware point of
view. If you pass a parameter in ms, there might be cases where the
actual number of bytes is lower than the DMA burst, it'll depend on
what frequency the sink operates at. There are some cases where
alsa-sink works at 8kHz (BT-SCO) or 48kHz (all other cases), a 6x
variability in the rewind behavior is difficult to handle.
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Routing of audio to loudspeakers or headphones

2010-08-25 Thread pl bossart

 Even when this is all done, you will still not get everything working
 100% perfectly just yet. Jack sensing is (apparently - not looked for a
 while) a mess and does not work reliably on all drivers. We need to fix
 that and probably will enable automatic port switching on jack status in
 due course. But until this comes in, when you plug in your headphones,
 you have to manually change the port in pavucontrol (labelled connector
 in gnome tools).

For jack sensing, we'd need a module that traps input events. ALSA
sends an input event when the headphone jack is inserted. This is
what's used in Meego (the detection isn't part of PulseAudio though).
You could then add enable the effect.
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] ALSA sink enumeration and multiple devices/subdevices

2010-08-24 Thread pl bossart

 In practice, NVIDIA GPUs only support sending video signals over at most
 two of these connectors at once, and hence the HD audio controller only
 allows two audio streams to be configured at once. The exact set used can
 be dynamically reconfigured by changing xorg.conf or using NVIDIA's tools
 to manipulate a running X server; similar to xrandr.

Ok, so now I understand your need to have multiple devices on the same
card. Point taken.
I am still not clear on the need to expose 4 devices, out of which 2
are known to be non-functional.
Why not expose to PulseAudio the only two devices that are configured
and functional?
And to go one step further why not present the devices if they are
connected to a receiver?
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] ALSA sink enumeration and multiple devices/subdevices

2010-08-23 Thread pl bossart

 If I hack /usr/share/pulseaudio/alsa-mixer/profile-sets/default.conf to
 change hdmi-stereo's device-strings value to e.g. hdmi:%f,0, hdmi:%f,1,
 etc., then I can cause pulseaudio to open whichever subdevice I wish. This
 proves to me that this is simply an enumeration issue and nothing more
 fundamental.

I beg to disagree..
I have done similar work and I think there's something fundamentally
broken in the ALSA/PulseAudio interaction for HDMI support(See my
posts on the ALSA mailing list). On my Intel IbexPeak, there's only
one HDMI device, but it is detected even though there's no cable
connected. I can play audio on HDMI even if I unplug the cable.
I would assume this is the same case for your Nvidia system, even if
you hacked the profile definition, you would end-up with a set of
detected profiles, but only one may work and only if there's a cable
connected. That would beat any audio policy/device manager/intelligent
routing logic.

For HDMI, I think the right solution is to have some ALSA hot-plug
event trapped by PulseAudio. Otherwise it's going to be really
confusing for users. With Nvidia hardware, they would have to manually
select which profile they want to play on, when they will want to play
on the device that has a cable attached.

Along the same lines, there's currently no means to know how many
channels the receiver supports. We could add HDMI
stereo/surround40/surround51/surround 71 profiles, but this is the
least user-friendly solution. Again we do need some hot-plug event to
set the relevant number of channels for the PulseAudio HDMI sink based
on ELD/EDID information.
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] ALSA sink enumeration and multiple devices/subdevices

2010-08-23 Thread pl bossart

 What I'm talking about is that pulseaudio is incapable of ever sending
 audio to anything other than the default device/subdevice within a card,
 irrespective of whether a cable is plugged in and signal being transmitted.

ok, I am not sure I understand why there are several devices in the
first place. Can you elaborate on what these 4 devices are? Can all
these devices be used concurrently with different streams,ie up to 4
independent HDMI outputs/cables? Or is each device stereo only, and
the hardware will multiplex channel pairs on the same HDMI link?
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH] Do not use tsched watermark if tsched is disabled

2010-08-18 Thread pl bossart

 * Pierre-Louis Bossart's version in git master sets a fixed margin of
 256 bytes, (configurable if you load the sink manually, i e not through
 module-udev-detect).

 * My version sets a fixed margin of 20 ms.

 * My version only changes non-tsched devices and keeps tsched having a
 margin of the current watermark, whereas Bossart's version changes both.

 I think a margin should be based on milliseconds rather than bytes (the
 amount of bytes varies with amount of channels, which means that we
 might get problems when people switch to surround output).

 I don't have an opinion on whether a fixed margin or watermark-based
 margin is better for tsched sinks.



 I presume Pierre-Louis will comment in due course. I'm sure he'll see
 this message.

 I'm annoyed I didn't appreciate that his fix would likely address the
 issue too when it was pushed, but such is life :D

Well I didn't see the link between my patch (from April) and the
problem David tried to fix either. Thanks Raymond for finding this
out.

Before making any conclusions, would the problem be solved with
David's patch using the equivalent of 256 bytes, that is 1.45ms
instead of 20ms? just want to make sure this is the same bug.

Yes the safeguard is needed in both cases, timer scheduling or good
ol' audio interrupts. This comes from limitations of the
snd_pcm_rewind() routine, you can rewind the appl_ptr all the way to
the hardware pointer, but you may have DMA transfers in flight that
cannot be rewound. For example HDaudio can fetch up to 128bytes, I
added a default a safeguard of 256bytes to be super safe, but in
theory this should be adjusted depending on how the DMA operates. The
DMA knows nothing about milliseconds, it behaves the same way no
matter the sampling rate it, which is the reason why bytes make more
sense, it's easier to correlate with the way the hardware works.
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] gst pulsesrc and default caps

2010-08-16 Thread pl bossart

 On Mon, 2010-08-16 at 06:42 +0300, Tanu Kaskinen wrote:
  I guess the problem is that pulsesrc doesn't know
  which source is going to be used before actually starts recording.

 No, that's not the problem. The problem is that pulsesrc doesn't use the
 proper flags when creating the stream: PA_STREAM_FIX_FORMAT,
 PA_STREAM_FIX_RATE and PA_STREAM_FIX_CHANNELS can be used to create the
 stream with whatever parameters are used by the device that the stream
 connects to.


 Thank you!!! i like this answer :D

I don't think that solves the problem. The performance issue is due to
the format/sample-rate conversion.
Using these flags essentially mean that you will record with whatever
native sampling-rate is used by the pulseaudio source (as specified in
daemon.conf) no matter what value is specified when the stream is
created.. It doesn't mean you are going to record at 16kHz natively in
pulseaudio. You will still have to go your src in gstreamer.
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] These ideas I've had for the better part of a month, forgive me for there length.

2010-08-16 Thread pl bossart

 The next stream type should be a pulse audio internal type(s) used for
 the mixing of mp3/ac3 and perhaps dts streams.  It's my understanding
 that ac3 uses vectors to describe 6 channels of sound much like a 2ch
 mp3.  If I'm not mistaken these vectors can be combined mathematically
 as-is to represent the combination of two sounds.  This would be a great
 achivement over any uncompress/combine/recompress senerio.

 Do you have any pointers to how this is done? If it's true that there
 really is a way to mix compressed streams without uncompressing first,
 then maybe volume adjustment is possible too?

Nah. no way you can mix streams without decompressing
(dequantization+inverse transform). The only thing you could do is mix
in the transform domain if both streams used the same transform and
window size, not a very common case.
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Rate/Timing issues when streaming over BT from iPhone.....

2010-08-16 Thread pl bossart

This is a known issue with module-loopback. If you look at this part
of the log, you'll see that there's something really wrong with how
the sample-rate is set:

 I: module-loopback.c: Old rate 43236 Hz, new rate 43300 Hz
 I: module-loopback.c: Loopback overall latency is 99.98 ms + 806.05 ms +
 39.69 ms = 945.71 ms
 I: module-loopback.c: Should buffer 34640 bytes, buffered at minimum 69240
 bytes
 I: module-loopback.c: Old rate 43300 Hz, new rate 44965 Hz
 I: module-loopback.c: Loopback overall latency is 99.98 ms + 781.78 ms +
 40.83 ms = 922.60 ms
 I: module-loopback.c: Should buffer 35976 bytes, buffered at minimum 134708
 bytes
 I: module-loopback.c: Old rate 44965 Hz, new rate 46568 Hz
 I: module-loopback.c: Loopback overall latency is 99.98 ms + 429.80 ms +
 40.62 ms = 570.40 ms
 I: module-loopback.c: Should buffer 37256 bytes, buffered at minimum 79028
 bytes
 I: module-loopback.c: Old rate 46568 Hz, new rate 45144 Hz
 I: module-loopback.c: Loopback overall latency is 100.00 ms + 409.27 ms +
 41.85 ms = 551.11 ms
 I: module-loopback.c: Should buffer 36120 bytes, buffered at minimum 73904
 bytes
 I: module-loopback.c: Old rate 45144 Hz, new rate 45044 Hz

By changing the sample-rate so often you end-up with cracks/noises.
I had similar problems when using an RTP link, the oscillations on the
sample-rate are not good.
Fundamentally I think there's something wrong with the logic Lennart
added to my original code. Every 5s or so, a timer fires, and a
message LATENCY_SNAPSHOT is sent to the input and output thread. Then
once both answers are received, the code determines what the sampling
rate should be. What I think is flawed is that this is not an atomic
way of getting the latency on both sides, and since we receive packets
the latency varies by large steps unlike for ALSA sinks/sources.
Without some filtering you end-up with too many variations of the
sampling rate.
Bottomline: this loopback code deserves some love, unfortunately I
don't have time to look into this. I had some success by limiting the
sample-rate oscilllations to 100Hz around the nominal value.
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH] AC3 passthrough support

2010-08-13 Thread pl bossart

 I guess I should have said this right away, but better late than never:
 this version looks good to me. Can we get this committed?

 Hmm, I had this marked as important in order to poke you on IRC so we
 could discuss but helpfully my mail client collapsed the thread and I
 cannot see the important label any more and I thus forgot...


 Sorry about that.

 If everyone is happen (which they are) then I'll commit it tonight when
 I'll try and do a bit of admin catchup on various things.

 Pushed with a single, entirely trivial formatting change.

Thanks!
To use this feature from other frameworks (gstreamer, etc), we will
need a tagged release to #ifdef code related to AC3 passthough for
backwards compatibility. Any idea when that might happen?
(would also be nice to close the gap between git master and meego
versions while we are at it...)
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Rate/Timing issues when streaming over BT from iPhone.....

2010-08-01 Thread pl bossart

 Script:
 #!/usr/bin/pulseaudio -vvvnF
 load-module module-alsa-sink device=default:CARD=Live sink_name=output
 rate=48000
 load-module module-bluetooth-device address=XX:XX:XX:XX:XX:XX
 path=/org/bluez/1662/hci0/dev_XX_XX_XX_XX_XX_XX profile=a2dp_source
 auto_connect=yes name=input rate=44100
 load-module module-loopback source=1 sink=0 rate=44100


It's not clear to me why you have two different rates. If you know the
incoming rate is 44.1kHz you could avoid resampling.
I think we also have a fundamental issue with the way the incoming
frequency is calculated in PulseAudio using latency estimates. I ran a
set of similar tests a while back with RTP streaming and the sampling
frequency estimated with the latency estimates varied wildly, by as
much as 10kHz. I had a patch to prevent variations of more than 1%
(which is already a lot), but that wasn't enough to remove all
frequency shifts introduced by the resampler.
We need to have some kind of long-term smoothing of these variations,
adjusting the sampling frequency with such variations isn't going to
work.

 Partial output:
 I: main.c: Daemon startup complete.
 I: module-loopback.c: Loopback overall latency is 100.04 ms + 0.00 ms +
 39.51 ms = 139.55 ms
 I: module-loopback.c: Should buffer 35280 bytes, buffered at minimum 0 bytes
 I: module-loopback.c: Old rate 44100 Hz, new rate 43218 Hz
 D: bluetooth-util.c: dbus: interface=org.bluez.AudioSource,
 path=/org/bluez/1662/hci0/dev_64_B9_E8_19_DD_FA, member=PropertyChanged
 D: module-bluetooth-device.c: dbus: interface=org.bluez.AudioSource,
 path=/org/bluez/1662/hci0/dev_64_B9_E8_19_DD_FA, member=PropertyChanged
 D: bluetooth-util.c: dbus: interface=org.bluez.AudioSource,
 path=/org/bluez/1662/hci0/dev_64_B9_E8_19_DD_FA, member=PropertyChanged
 D: module-bluetooth-device.c: dbus: interface=org.bluez.AudioSource,
 path=/org/bluez/1662/hci0/dev_64_B9_E8_19_DD_FA, member=PropertyChanged
 I: main.c: Got signal SIGUSR2.
 I: module.c: Loaded module-cli-protocol-unix (index: #3; argument: ).
 I: module-loopback.c: Loopback overall latency is 99.98 ms + 0.00 ms + 39.51
 ms = 139.49 ms
 I: module-loopback.c: Should buffer 34576 bytes, buffered at minimum 0 bytes
 I: module-loopback.c: Old rate 43218 Hz, new rate 43236 Hz
 I: client.c: Created 0 UNIX socket client
 D: bluetooth-util.c: dbus: interface=org.bluez.AudioSource,
 path=/org/bluez/1662/hci0/dev_64_B9_E8_19_DD_FA, member=PropertyChanged
 D: module-bluetooth-device.c: dbus: interface=org.bluez.AudioSource,
 path=/org/bluez/1662/hci0/dev_64_B9_E8_19_DD_FA, member=PropertyChanged
 I: module-loopback.c: Loopback overall latency is 99.99 ms + 400.66 ms +
 42.02 ms = 542.67 ms
 I: module-loopback.c: Should buffer 34592 bytes, buffered at minimum 2560
 bytes
 I: module-loopback.c: Old rate 43236 Hz, new rate 43300 Hz
 I: module-loopback.c: Loopback overall latency is 99.98 ms + 806.05 ms +
 39.69 ms = 945.71 ms
 I: module-loopback.c: Should buffer 34640 bytes, buffered at minimum 69240
 bytes
 I: module-loopback.c: Old rate 43300 Hz, new rate 44965 Hz
 I: module-loopback.c: Loopback overall latency is 99.98 ms + 781.78 ms +
 40.83 ms = 922.60 ms
 I: module-loopback.c: Should buffer 35976 bytes, buffered at minimum 134708
 bytes
 I: module-loopback.c: Old rate 44965 Hz, new rate 46568 Hz
 I: module-loopback.c: Loopback overall latency is 99.98 ms + 429.80 ms +
 40.62 ms = 570.40 ms
 I: module-loopback.c: Should buffer 37256 bytes, buffered at minimum 79028
 bytes
 I: module-loopback.c: Old rate 46568 Hz, new rate 45144 Hz
 I: module-loopback.c: Loopback overall latency is 100.00 ms + 409.27 ms +
 41.85 ms = 551.11 ms
 I: module-loopback.c: Should buffer 36120 bytes, buffered at minimum 73904
 bytes
 I: module-loopback.c: Old rate 45144 Hz, new rate 45044 Hz
 I: main.c: Daemon shutdown initiated.

 Thanks in advance

 Alex

 a...@apics.co.uk

 Homer Simpson: Facts are meaningless. You could use facts to prove anything
 that's even remotely true!
 ___
 pulseaudio-discuss mailing list
 pulseaudio-discuss@mail.0pointer.de
 https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss


___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH] AC3 passthrough support

2010-07-16 Thread pl bossart

 +    PA_SINK_PASSTHROUGH = 0x0100U
 +    /** The latency can be adjusted dynamically depending on the
 +     * needs of the connected streams. \since 0.9.22 */
 +

 Copy-paste mistake in the documentation.

No this was done on purpose. We are already at 0.9.21 so the next
version is logically 0.9.22?

 Also, PA_IDXSET_FOREACH can be used here. Or actually you don't need to
 iterate through the set at all, you could just check the first input -
 if that's a passthrough input, then it's the only input anyway, and if
 it's not a passthrough input, then none of the inputs is a passthrough
 input.

Yes. I wrote some code but somehow I dropped it. Will fix it.

 I wonder if we should return a more descriptive error in case the sink
 is used by other streams. Returning just invalid argument doesn't
 allow apps to give informative error messages. What do you think?

Maybe adding an error code for passthrough connections would do.
INVALID is too vague I guess?

 somewhere in pa_sink_input_new, and checks in protocol-native.c to
 prevent that assertion from firing. That is, refuse to create
 passthrough streams that also have volume specified by the client.

I think it's better to ignore volume settings rather than refuse the connection?
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Changing default soundcard on attach/detach of soundcards

2010-07-16 Thread pl bossart

 Well right now there are several projects (outside of my own) going on
 in this field, but there does seem to be a little bit of disparity with
 upstream people.

 One project specifically is coming from the ALSA side and will get
 support in PA. This project is very likely to become the defacto method
 of operation on embedded systems and thus I would hope that people at
 MeeGo would talk more openly about what they are doing so as not to
 reinvent the wheel.

If you are talking about the audio scenarios developed by Liam, I
don't think there's any sort of conflict. it's my understanding that
the scenarios are mainly to configure the hardware routing and
performance of a given audio device using specific settings (eg voice
volume, etc).
This thread is more about what output will be used if you have
multiple audio accessories or peripherals. It's one level higher I
guess.
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH] AC3 passthrough support

2010-07-16 Thread pl bossart

Second version to address Tanu's feedback. Should be good enough by
now for actual use.


0001-AC3-passthrough-support.patch
Description: Binary data
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH 1/3] alsa: fix mixer profiles, add passthrough config

2010-07-14 Thread pl bossart

 Actually it doesn't sound good. Mainly due to the missing files you
 didn't include!

 Can you cook up another patch that includes the:
  modules/alsa/mixer/paths/iec958-*
 files?

 I should have tested it properly, but such is life :p

Sorry about this. I should have been more cautious... Here's the first
patch with the missing files.


0001-alsa-fix-mixer-profiles-add-passthrough-config.patch
Description: Binary data
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Cannot have iec958:0 and a52:0 simultaneously?

2010-07-14 Thread pl bossart

On Wed, Jul 14, 2010 at 2:10 PM, Michael Rans mcar...@yahoo.co.uk wrote:
 I have a theory that the $CARD doesn't work for me and may not for others
 because of the way in which the %f in a52:%f is generated.

 Would I be right in saying that %f is incremented for each source or sink
 ie. you cannot have both iec958:0 and a52:0?

You seem to have an odd hardware configuration. Can you provide the
output of aplay -l?
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] {PATCH][RFC] AC3 passthrough support

Adding this in /etc/asound.rc (more exactly
/etc/alsa/pulse-default.conf on my Fedora box) work fine:

pcm.a52 {
   @args [CARD]
   @args.CARD {
   type string
   }
   type rate
   slave {
   pcm {
   type a52
   bitrate 448
   channels 6
   card $CARD
   }
   rate 48000 #required somehow, otherwise nothing happens in PulseAudio
   }
}

a52:0 is detected by PulseAudio and the encoded output shows as
'Digital Surround 5.1 (IEC958/AC3) in pavucontrol.

I just finished testing all the changes I posted yesterday. Works
flawlessly, I can switch from 2ch PCM over SPDIF to 5.1 still over
SPDIF but re-encoded with a52, and unlike the passthrough case I can
mix the multichannel content with alerts or system tones.
The only bug I found is that if I change the individual volume on one
of the channels, there's a ringing noise introduced, and it does not
go away unless I kill the stream.

Will prepare a set of patches, Colin it'd be great if you can merge
them in git master.
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

[pulseaudio-discuss] [PATCH 2/3] alsa: fix failed assertion when using a52 plugin




0002-alsa-fix-failed-assertion-when-using-a52-plugin.patch
Description: Binary data
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

[pulseaudio-discuss] [PATCH 3/3] alsa: disable rewinds when using ALSA plugins




0003-alsa-disable-rewinds-when-using-ALSA-plugins.patch
Description: Binary data
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH 1/3] alsa: fix mixer profiles, add passthrough config