Hi all,
I am trying to write a module that keeps track of all connections to a sink.
I started from the code in module-stream-restore.c, read detailed
explanations from Lennart and the hooks work well. Except for the unlink
hook. Somehow looking at the client name with the proplist causes a seg
.
From: pulseaudio-discuss-boun...@mail.0pointer.de [mailto:
pulseaudio-discuss-boun...@mail.0pointer.de] On Behalf Of pl bossart
Sent: 2009年1月21日 0:13
To: General PulseAudio Discussion
Subject: Re: [pulseaudio-discuss] why command_cork_playback_stream() will
be invoked many times?
Hi
Hi Lennart,
I like the idea of modules being able to send events to a client. That would
work for clients who connect directly to pulseaudio, with some additional
modifications internally. For example the pulsesink would sent a message on
gst_bus to request the app to pause.
However in the case
Hi everyone,
Gapless playback is frequently listed as an issue by users, they complain
about gaps in the audio when the player jumps from one playlist entry to the
next one. So far each player has their own solution (or no support at all).
Basically the idea is that while you are playing a stream,
On Thu, Apr 2, 2009 at 8:32 PM, Lennart Poettering
lenn...@poettering.netwrote:
AFAICS the ALSA hdmi: device does not rearrange the channels in any
way. Hence it probably exposes the raw underlying channel order. The
question of course is how the channel map nego in ALSA works for the
cases
Lennart,
In another thread on JACK/PA integration, you wrote:
I am sorry to inform you that eventually PA will use D-Bus for client
communication too. Already now building PA without D-Bus is not really
supported anymore (read: noone bothers to check if those builds still
compile).
Could you
Lennart,
I was looking at the latest code and in git-master I saw changes to
the alsa-sink/source files, and a new 'reserve' module. Can you please
shed some light on why PA would try to lock a device, or resume a sink
when an ALSA device becomes 'unused'. My understanding was that apps
using ALSA
Thanks Lennart,
The device reservation logic is intended for cooperation with the JACK
sound server: i.e. when JACK wants direct access it can have it.
http://0pointer.de/blog/projects/device-reservation.html
Other than that session switching needs cooperating PA
instances. i.e. if you
While I am at it, what was the rationale for the new PA_SINK_IDLE
state introduced in 0.9.15. From what I understand this is a running
sink with no incoming data (no non-corked inputs). But the state
transitions in alsa-sink essentially consider this state as a
PA_SINK_RUNNING one.
So if you have
The resampling part makes complete sense. Palm are using a polyphase
fixed-ratio filter; this will be more optimized than the variable-rate
interpolation provided by libspeexdsp (no need to be variable-rate for
file playback, only needed when devices are not clocked off of the
same reference). The
Hi Lennart,
this might be a silly question but how would you handle transitions
between speakers and headset profiles. When the user plugs or unplugs
their headsets, you would need to change profiles or you would still
not use the correct control. Not clear to me how the jack detection is
Hi Lennart,
I see supporting AC3 pass-thru, Vorbis/Speex decompression and CELT
compression+decompression as different sides of a (three-sided...)
medal.
I can see why you'd want to support AC3 pass-thru (multichannel
receiver) and CELT (network), it's not clear why you'd want
Vorbis/Speex
Howdy,
Since this was missing in PulseAudio, I created a loopback module
where input sound can be redirected to a sink. That removes the need
for the silly parec|pacat workaround.
Basically the module creates both a sink_input and source_output. When
there's data available from the source, a push
Thanks Lennart for your comments.
pa_memchunk is a structure that is just a short way to store a pointer
plus and index and a size. You can allocate it on the stack or
wherever you want, but it's your job to allocate it, and how you do it
is up to you. Seldomly you'd malloc() it explcitly
On Tue, Aug 25, 2009 at 8:00 PM, Lennart
Poetteringlenn...@poettering.net wrote:
On Tue, 18.08.09 10:42, pl bossart (bossart.nos...@gmail.com) wrote:
Here the module-loopback code, turns out we can contribute freely to
PulseAudio. Comments welcome.
Pierre, I have merged this today and fixed
Poetteringlenn...@poettering.net wrote:
On Wed, 26.08.09 08:43, pl bossart (bossart.nos...@gmail.com) wrote:
Here the module-loopback code, turns out we can contribute freely to
PulseAudio. Comments welcome.
Pierre, I have merged this today and fixed all the outstanding issues
I pointed out
Colin,
i will talk about the reasons that led to the developments of the
audio manager during the LPC audio track.
cheers
Pierre
On 9/19/09, Colin Guthrie gm...@colin.guthr.ie wrote:
While looking into some pulseaudio but reports on this list, I learned about
Mobin's AudioManager which appears
pactl load-module module-loopback
source=alsa_input.usb-TerraTec_PHASE_26_USB_24_96rec__11001-00.analog-stereo
sink=alsa_output.usb-TerraTec_PHASE_26_USB_16_48__11001-00.analog-surround-41
latency_msec=1
fails.
Fails? Please elaborate? What's the log output PA generates when you
do this?
I checked the source code, and latency_msec is missing from the list of
valid module arguments. Attaching a patch to add it.
Yes. this is a known issue, I provided a fix last month. Lennart, you
want to apply this patch...
___
pulseaudio-discuss
Hi there,
I am trying to understand some performance measurements I did this
week. I have a test app that decodes audio and writes a decoded buffer
with pa_simple_write(). Depending on the size of the buffer I pass to
PulseAudio, I see a ~20% variation in the core activity (bigger
buffers are
If you need ac3 pass-thru then you need to bypass PA. Just make sure
you are not using the SPDIF port for PA (use g-v-c or pavucontrol and
make sure the sound card is notconfigured for any of the 'digital
iec985' modes).
If you use AC3 pass-thru, what you are really sending over the SPDIF
Oops. You patch is still in my queue. There were some issues I didn't
perfectly like, but it was not straightforward to fix them. So lazy as
I am I just added your patch to my queue, so that I look into it
later.
Sorry. I have now commited Tor-Björn's patch as it was quite trivial.
Just make sure PA doesn't grab the device, and then tell your app to
use the low-level spdif-pass-thru directly. How that is configured has
nothing to do with PA, and in fact stays exactly the same whether you
run PA or not.
You could use the device reservation utilities for this. When you
Hi all,
I have lost the afternoon chasing an audio quality issue with PA
configured with tsched=0 and small fragments (30ms). I am doing this
on purpose to profile the behavior of PulseAudio with lots of wakeups
and samples provided in chunks at once.
With the latest 0.9.19 version I have cracking
If you compare the output of snd_pcm_dump() for 0.9.15 and 0.9.19 on
your card, is there any obvious difference?
(snd_pcm_dump() is called as part of the normal setup these days and
dumped to stderr when debug logging is on. the snd_pcm_dump() output
looks like this: http://fpaste.org/X9Vh/)
Here's the error I get with git master when compiling on an older Thinkpad X41:
pulsecore/core-util.c: In function ‘pa_running_in_vm’:
pulsecore/core-util.c:3087: error: can't find a register in class
‘BREG’ while reloading ‘asm’
pulsecore/core-util.c:3087: error: ‘asm’ operand has impossible
Hi,
I am still trying to configure PulseAudio for a low-latency app, and I
could not figure why the latency reported is much higher than what I
specified. For example, with tsched=0 and four fragments of 5ms, the
latency wouldn't go below 40ms, no matter how I specified the latency
parameter.
Looks to me more as an RTP issue than a loopback one, it does look
like the sample-rate is changed both in module-rtp-recv and
module-loopback. Not sure how this would work. And why would you want
low-latency for network traffic, you will by construction be limited
by the network?
You need to
I recently submitted two patches for ALSA kernel stack that
will guarantee wake_ups to happen at each periodic interrupt.
Currently that is not the case when avail_min is greater than
period size.
It's unclear to me why you would want to set avail_min to more than a
period and still get a
I also don't think mixing PCM streams in hw would bring much added value.
However the initial post mentioned that the DSP can handle decoders as
well. That's a completely different story. If you have compressed
streams, you could benefit from offloading the decompression and mix
to the DSP. The
So, my question is: Does pulseaudio's SBC implementation support
dynamically
changing bit rates and frame lengths? If so, how and where?
No, we don't support this right now.
We probably should though. Please file a bug in the BTS so that we
don't forget about this. Even better: prepare
Pierre, what do you mean by the size of the PCM? Do you mean the frame
length? If so, I am confused, because the frame length explicitly depends on
the bitpool parameter. So, the frame length will change.
You provide nsubbands*nblocks samples as input. This cannot change.
Moreover, I think
This is probably a question for Lennart...
I am somewhat confused on how the playback latency should be
estimated. I was under the impression that pa_stream_get_latency() was
the way to go, but I came across some code in gstreamer/pulsesink
where the latency is retrieved with
The patches I am about to post provide two modules that could be of
interest to the PulseAudio community.
module-virtual-sink is a template for the addition of PCM processing.
It's basically based on the LADSPA module, I use it for internal
experiments and will enhance it in the future.
From 78dfa037f869b8fe0613260fdd999693b6305e19 Mon Sep 17 00:00:00 2001
From: Pierre-Louis Bossart pierre-louis.boss...@intel.com
Date: Thu, 11 Feb 2010 15:44:11 -0600
Subject: [PATCH 1/3] [virtual-sink] Boilerplate virtual sink to add PCM processing
---
src/modules/module-virtual-sink.c | 635
From 719bea45da05b13f2ad3fc33a00fd09253614f6f Mon Sep 17 00:00:00 2001
From: Pierre-Louis Bossart pierre-louis.boss...@intel.com
Date: Thu, 11 Feb 2010 15:45:35 -0600
Subject: [PATCH 2/3] [virtual-source] boilerplate virtual source for PCM processing on inputs.
---
From 0e812456ba0532202b518a66cd35406ba6c964b8 Mon Sep 17 00:00:00 2001
From: Pierre-Louis Bossart pierre-louis.boss...@intel.com
Date: Thu, 11 Feb 2010 15:46:41 -0600
Subject: [PATCH 3/3] [Makefile.am] enable virtual-source and virtual-sink
---
src/Makefile.am | 16 ++--
1 files
Actually I had I really wanted to write what I wrote. i.e. passing
NULL as buffer_attr means use the default latency (which is
250ms). Passing a buffer_attr with all values set to -1 means i don't
care about latency (which ideally means 2s latency).
So, yes, I actually meant what I did in
module-virtual-sink is a template for the addition of PCM processing.
It's basically based on the LADSPA module, I use it for internal
experiments and will enhance it in the future.
This definitely makes sense, especially when we'll eventually get the
filtering logic I have mentioined a
Actually I had I really wanted to write what I wrote. i.e. passing
NULL as buffer_attr means use the default latency (which is
250ms). Passing a buffer_attr with all values set to -1 means i don't
care about latency (which ideally means 2s latency).
So, yes, I actually meant what I did in
2. I also have a problem with sound distortions (mostly much higher
and quicker voice) several seconds after loading the
loopback-module (source is a bluetooth-headset and sink is my
soundcard). After some seconds the distortions disappear and
everything is fine. I found out that
I did some testing on our LAN with one laptop sending audio over rtp
and the other receiving the data and playing it locally. The
estimation of timing is very jittery, and the sampling rate is changed
in very large steps (eg. 44.1-53kHz). The current code allows for 50%
increases without setting a
On Mon, Apr 5, 2010 at 4:25 PM, Mark Brown broo...@sirena.org.uk wrote:
On Mon, Apr 05, 2010 at 02:23:50PM -0500, pl bossart wrote:
Ideally we should enforce a stronger smoothing on the time estimation,
there's no reason why such variations should occur. I forced the
smoothing history to 20s
This is a patch to fix rewind issues. It has the potential to break
audio in Linux, so I would really appreciate it if others could give
it a try and test on their systems. The new rewind_safeguard should be
tuned to the DMA burst size plus some headroom; I chose a default
value of 256 bytes but
Howdy,
When PulseAudio is used and all PCM is routed through PulseAudio
(Fedora, Meego, etc), the notion of ALSA periods isn't very useful.
PulseAudio uses a timer to refill buffers and the period interrupts
are not used at all.
So why not disable them entirely to reduce the number of wakeups?
Hi Clemens,
When PulseAudio is used and all PCM is routed through PulseAudio
(Fedora, Meego, etc), the notion of ALSA periods isn't very useful.
So why not disable them entirely to reduce the number of wakeups? ...
There are probably some cases where you don't want this type of
behavior
Hi Liam,
How do you handle any clock drift here between the HDA hardware
interface clock and the PA timer ?
Good question. This is already handled by PulseAudio. The timer isn't
programmed with a fixed value but is adapted precisely to track
differences between system time and audio time.
The rules documented in http://pulseaudio.org/wiki/GitBranches seem
sensible to me, but the documentation doesn't match reality: according
to the wiki page, there should be a branch named 0.9.21-stable, but
there isn't, and all commits in stable-queue should also be in master,
but they
Hmm, I had to think about this a bit, but I do agree now tha
In the long run, this should probably be done by ALSA (or at least tuned
to some value reported by ALSA), but the patch makes a lot of sense to
me, and certainly more sense that the watermark value that we currently
stay away from
This patch looks very interesting and desirable. This is something have
long been waiting for.
I wonder how this actually relates to
snd_pcm_sw_params_set_period_event() though.
snd_pcm_sw_params_set_period_event() defines whether or not you will
have poll wakeups when a period elapses. But
Here's a proposal for an alsa-lib modification to allow applications
to disable interrupts (if the hardware can do so).
I used the flag field in hw_params, this looked like a good candidate
to convey this information needed by the driver. I don't really like
adding two new routines, but I don't
Some care would need to be taken with regards to detecting xruns.
I think the alsa code currently uses the interrupt callback to detect this.
I have seen a Windows 7 machine happily loop the audio buffer
uncontrollably, so I assume it has problems detecting xruns as well.
When the PulseAudio
It seems the requirement is just to have as least wakeups as possible
in order to
maximize power savings.
If so, then how about setting the period size slightly smaller than
the ring-buffer: the
difference being just enough to refill the ring buffer. Of course, you
would have to
enforce
Please, use tabs for block indention for alsa-lib.
Right, I used the same .emacs style for pa and alsa-lib...Fixed now
Are you sure that you're using new libraries? 'ldd' and 'nm' tools will help
you to determine what's wrong with symbols.
Argh.. For some reason Fedora has a preinstalled
ok. It works just fine now. Can I send a patch against alsa-kmirror or
do you prefer against alsa-kernel? I use the former to recompile only
the audio modules.
It does not matter. I accept both forms (the diffence between trees is
minimal). Also, you can use alsa-driver with alsa-kernel
AFAIU, the only issue is lack of ability to fine-tune period size of
DMA runtime.
Otherwise, for the requirement, having period-size almost equal
to ring-buffer serves better than disabling interrupts and using timer
based updating, more so for VMs with inaccurate timer source.
Then I
The biggest problem I can foresee is the handling of PCM position.
In the current implementation, the PCM position continues to go over
the buffer size until the certain boundary that is close to long int
max. Without interrupts (i.e. snd_pcm_period_elapsed()), this
position update won't
Here is my latest set of patches before I forget about them.
Still some work to be done on the alsa-lib one, for some reason the
hw_param-flags field I used gets overwritten if I don't use the
hw_device. I suspect this is due to some black magic with the
pcm-hw_flags when slave devices are used.
Instead of a new field in snd_pcm_hardware, you should better use a new
flag so that userspace also knows about this capability.
Yes this is much better indeed.
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
2) The avail_min parameter in sw_params was overlooked. The lowlevel
drivers can use this value to compute the wake-up point and set hw
appropriately, to do wake-up at requested time. We can add a support
functions like return how many samples are expected to be transferred
for next
2) The avail_min parameter in sw_params was overlooked. The lowlevel
drivers can use this value to compute the wake-up point and set hw
appropriately, to do wake-up at requested time. We can add a support
functions like return how many samples are expected to be transferred
for next
If there is a skeleton module that does just that it would be great,
if not can you please give me some direction.
look at module-virtual-sink and add your code where indicated.
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
It's been more than a year that this topic shows as 'being on the
roadmap', but for now the reality is that people bypass PulseAudio to
hear multichannel sound. I thought solving this would be a nice summer
skunkworks project while everyone is busy increasing their chances of
skin cancer.
Here's
Wow, someone actually reads my mails...
Here's the deal: formatting an AC3 file into the required IEC format
takes about 30 lines of code, this can be done in the application that
connects to PulseAudio.
Do you plan to do it (the formatting) inside or outside libpulse?
Outside (like in
Hmm, the client only asks for a timing updating if the seeking triggered
by a write corrupted the timing info and we hence need new data. A
normal write (i.e. with offset=0 and seek=PA_SEEK_RELATIVE) should no
trigger a timing update.
The Gstreamer folks use PA_SEEK_ABSOLUTE with a non-zero
Here's an enabling patch for the next goal of supporting AC3 passthrough.
This patch allows to play locally with the analog output or play out
on the SPDIF output. Switching from one to the other can be done
through the pavucontrol/configuration tab.
I added a new path and profile so that hw
Oh I see you completely removed the a52 plugin support... any reason?
I'd rather the support was just fixed rather than removed completely.
My patch should fix the assert, but not sure what the next stage of
fixing it would be.
Also your patch seems to use hw: names in the profiles. This is
I appreciate that the mapping iec958-surround-40 may be irrelevant
seeing as spdif only support stereo PCM, but the I don't really follow
the duplicates what PA could do bit. Can you explain a bit?
Surround40 only modifies the channel mapping to generate 4ch.
PulseAudio could do this natively
On Mon, Jun 21, 2010 at 1:16 PM, Colin Guthrie gm...@colin.guthr.ie wrote:
'Twas brillig, and Tanu Kaskinen at 21/06/10 18:35 did gyre and gimble:
Didn't Coling specifically ask proposals NOT involving passthrough?
Yup :), and as I was heading home today I thought of a good example: games!
I really think iec958 is very much the *right* think to do. Have a look
at the alsa config files that set these things up. They are not rocket
science but they do allow this kind of thing to work, and perhaps the
ALSA_IEC958_DEVICE environment variable is exactly what you want but it
works
here's a first work-in-progress set of patches. I managed to route
iec958 formatted data through PulseAudio, works fine but there's still
a lot to do.
As discussed on the mailing list, I added a new flag to pa_stream
connections, and also added a flag for the sink in case it can handle
In your design the PA_SINK_PASSTHROUGH flag means that the sink can be
used both for exclusive passthrough streams and for normal streams. Are
you sure we can keep that promise for all future passthrough sinks too?
It would be cleaner to have strict separation between passthrough sinks
and
I agree that it's not really a good solution to require the user to
change the card profile manually to enable passthrough via spdif. But as
I said, a separate module could take care switching between the profiles
as needed.
I don't understand your proposal. What do you mean by separate
1. I was wondering if MP3/DTS/AC3 passthrough is at the discussion point
only or is someone actively looking at developing it?
AC3 passthrough works (see patches at start of thread). That said
there are still some opens and feedback is still welcome. I guess this
will be part of Meego at some
However, I see that my channels are still at two:
$ pactl list
[snip]
Sink #0
State: SUSPENDED
Name: alsa_output.pci-_02_09.0.analog-stereo
Description: CS 4614/22/24/30 [CrystalClear SoundFusion Audio
Accelerator] Analog Stereo
Driver: module-alsa-card.c
But I still need to go via the rate converter to the a52 encoder in
asoundrc.
Have you set the default sink frequency to 48kHz in
/usr/etc/pulse/daemon.conf? This should handle resampling in
PulseAudio.
Still not clear why rewind doesn't work.
- Pierre
Again, when reading the thread further, I found the reason why
snd_pcm_hw_params_can_rewind doesn't exist - it was replaced by
snd_pcm_rewindable. Pulseaudio doesn't call that. I added a patch (not
formatted as a proper patch) to ticket 839 that adds the
snd_pcm_rewindable check to the alsa
2. Replace: pa_sink_set_max_rewind(u-sink, u-hwbuf_size); with:
if(strcmp(u-device_name, a52) == 0) {
pa_sink_set_max_rewind(u-sink, 0);
} else {
pa_sink_set_max_rewind(u-sink, u-hwbuf_size);
}
NAK. This does not work for me. You need to rewind also in the
Even with this fix, the sink doesn't seem to do anything:
Actually discard this comment, it looks like it's crunching data if
you specify the rate in asound.conf.
# Encode AC3 - Directly on hardware
pcm.Filter_A52Encode {
type a52
bitrate 448
channels 6
}
# Rate Converter to 48kHz,
This may be an obvious question, but what is the
@args.0 {
type integer
}
for?
Is that what you meant by Adding the argument removes the need to exit the
profile. and if you did, I didn't understand at what point I had to exit
the profile. Can you explain? Sorry if I'm being
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
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
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
On Tue, Jul 13, 2010 at 4:13 PM, Colin Guthrie gm...@colin.guthr.ie wrote:
Is this one doing anything currently? I mean does this passthrough
profile actually work without any code changes not yet upstream?
Sorry if this is dumb question as I've not really had as much time of
late as usual so
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
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
+ 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
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
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
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
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
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:
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
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 +
* 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
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
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
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
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
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
1 - 100 of 178 matches
Mail list logo
