[pulseaudio-discuss] cmipci, pulseaudio and 5.1 — unable to contol center/LFE
Hello,
I have a CM8738-MC6 soundcard with 5.1 analog surround. With pulseaudios
5.1 profile I am unable to control center and LFE channels. Changing the
values for these channels achieves nothing. This is partly due to the
way the soundcard works in alsa. Quoting ALSA Wiki from
http://alsa.opensrc.org/index.php/Cmipci:
CM8x38 chip can use ADC as the second DAC so that two different stereo
channels can be used for front/rear playbacks. Since there are two DACs,
both streams are handled independently unlike the 4/6ch multi-channel
playbacks in the section below.
As default, ALSA driver assigns the first PCM device (i.e. hw:0,0 for
card#0) for front and 4/6ch playbacks, while the second PCM device
(hw:0,1) is assigned to the second DAC for rear playback.
In my case, it seems that center/LFE are on hw:1,1 (with other channels
being on hw:1,0). I have tried adding followings to .asoundrc:
pcm.softvol {
type softvol
slave {
pcm hw:1,1
}
control {
name SoftMaster
}
}
pcm.dsp1 {
type plug
slave.pcm softvol
slave.channels 6
route_policy duplicate
}
pcm.!default {
type plug
slave.pcm softvol
slave.channels 6
route_policy duplicate
}
With this config I can control volume for all the channels
simultaneously in alsa using the Softmaster control.
However, I am lost about how can I make this work in pulseaudio.
I can edit analog-output.conf.common to make pulseaudio control
SoftMaster, but this control doesn't affect sounds routed through
pulseaudio.
Can anybody give me an advice of how to configure my sound setup so I
can change volume for all the channels simultaneously in pulseaudio?
regards,
Erik Boritsch
___
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-17 21:10, Colin Guthrie skrev: 'Twas brillig, and David Henningsson at 17/08/10 19:20 did gyre and gimble: According to what you say in that bug, you could reproduce it yourself by setting tsched=0, so I'm eager to hear if this fix fixes your issue as well. Yeah I was able to reproduce it pretty easily with the chordtest.sh script attached to the bug. After the third tone, it started to sound terribly distored. After applying your patch, I tried several times and got a perfect run each time :) \o/ The patch is against stable-queue, and Raymond commented that git master has a slightly different way of solving the problem. To compare them: * 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. -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic ___ 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
'Twas brillig, and David Henningsson at 18/08/10 09:28 did gyre and gimble: 2010-08-17 21:10, Colin Guthrie skrev: 'Twas brillig, and David Henningsson at 17/08/10 19:20 did gyre and gimble: According to what you say in that bug, you could reproduce it yourself by setting tsched=0, so I'm eager to hear if this fix fixes your issue as well. Yeah I was able to reproduce it pretty easily with the chordtest.sh script attached to the bug. After the third tone, it started to sound terribly distored. After applying your patch, I tried several times and got a perfect run each time :) \o/ The patch is against stable-queue, and Raymond commented that git master has a slightly different way of solving the problem. To compare them: * 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 Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] cmipci, pulseaudio and 5.1 — unable to contol center/LFE
Erik Boritsch schrob:
I have a CM8738-MC6 soundcard with 5.1 analog surround. With pulseaudios
5.1 profile I am unable to control center and LFE channels.
[...]
In my case, it seems that center/LFE are on hw:1,1 (with other channels
being on hw:1,0). I have tried adding followings to .asoundrc:
[...]
With this config I can control volume for all the channels
simultaneously in alsa using the Softmaster control.
However, I am lost about how can I make this work in pulseaudio.
I can edit analog-output.conf.common to make pulseaudio control
SoftMaster, but this control doesn't affect sounds routed through
pulseaudio.
(Warning: I'm just guessing here...)
By default, PA finds soundcards via module-{udev-|hal-|}detect, which
probably will pick up your physical card rather than the alsa !default.
So you might try something like
| load-module module-alsa-sink device=softvol
in default.pa to make PA use the softvol device.
Alternatively, you could try to duplicate the alsa config by following
http://www.pulseaudio.org/wiki/FAQ#CanIusePulseAudiotocombinetwostereosoundcardsintoavirtualsurroundsoundcard
HTH,
Jan
--
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
signature.asc
Description: Digital signature
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] cmipci, pulseaudio and 5.1 — unable to contol center/LFE
'Twas brillig, and Jan Braun at 18/08/10 14:19 did gyre and gimble:
Erik Boritsch schrob:
I have a CM8738-MC6 soundcard with 5.1 analog surround. With pulseaudios
5.1 profile I am unable to control center and LFE channels.
[...]
In my case, it seems that center/LFE are on hw:1,1 (with other channels
being on hw:1,0). I have tried adding followings to .asoundrc:
[...]
With this config I can control volume for all the channels
simultaneously in alsa using the Softmaster control.
However, I am lost about how can I make this work in pulseaudio.
I can edit analog-output.conf.common to make pulseaudio control
SoftMaster, but this control doesn't affect sounds routed through
pulseaudio.
(Warning: I'm just guessing here...)
By default, PA finds soundcards via module-{udev-|hal-|}detect, which
probably will pick up your physical card rather than the alsa !default.
So you might try something like
| load-module module-alsa-sink device=softvol
in default.pa to make PA use the softvol device.
I think that rather than going through hoops, you can just pass the
control= argument and the load of the sink and pass instead the
SoftMaster control name.
Look at the pulseaudio -vvv output to see how the sink is loaded and
then copy those arguments exactly and add the control=SoftMaster to the
loop.
Alternatively you can find a way to plugin the softvol control into your
card properly via alsa configuration (i.e. by looking at the files in
/usr/share/alsa/ and seeing how to override things)
Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/
Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] Version numbers rollup releases
Hi, This has been discussed before but it's becoming an issue now. There are some bugs that need patches and work around in client applications which actually check that the fix is in PA itself to take appropriate action (a recent example would be knowing that PA has XCB support for client side X11 interaction vs. Xlib and taking appropriate action to call XInitThreads() or not). In a recent case VLCs pulse output had to call XInitThreads work around bug 799 which is a valid thing to do (it's a very convoluted situation that means that pushing this thing up to the application layer is awkward as the whole PA layer in libvlc is itself just an option - the app just produces sound - this is further complicated by any alsa clients going via alsa-pulse layer etc. Obviously libpulse using XCB is the right solution here, but we need to know in VLC whether or not to call XInitThreads (because libpulse is using Xlib), or not (because it's now using XCB) Anyway, obviously the clearest way to do this is a simple PA_VERSION_CHECK() call in the client side code. For that we can't just apply a patch to stable-queue; we need a release. Now on to the next point: More frequent releases. I know that Lennart doesn't like doing releases, but I think I speak for everyone of us triaging bugs and working on patches for the stable-queue branch would prefer to have more interim releases (especially in the current case where 0.9.22 has been so long in the kitchen due to systemd distractions!). I'm happy to do the necessary work of tarball creation and announcements but I think we need a clearer policy on version numbers to go along with such a scheme. I'm therefore going to propose something: Major changes will result in a PA_MINOR bump. For as long as I've been involved in PA (which is quite a while now) it's only ever had PA_MICRO bumps... I'm not sure if there is a particular reason for it (perhaps 9 is Lennart's lucky number?), but I don't see any real reason not to push that up to 10 and beyond (for clarity I don't think it's relevant to consider any kind of PA_MAJOR change - it should be reserved for then the library ABI needs to break). So, in short, I'd like to take the following actions: 1. Rename the milestone 0.9.22 to 0.10.0. The current git master should ultimately become 0.10.0 (with all it's DBUS funkiness). 2. Tag stable-queue as 0.9.22 and release a tarball[1] Lennart: As always you are in charge, but keeping a track on things is so much easier if I don't have to explain the fact that there are 170+ patches to apply on top of the last stable release. If you are happy to adopt this numbering approach, I'll take the extra load that results from doing more interim releases. I know that distro policy means that version bumps in packages for stable distros are generally frowned upon by distro release managers, but I get the feeling that this is slightly more relaxed these days (I know it is in Mandriva) if the upstream project is quite clear about their recommendations and their versioning scheme. I mean if 0.10.x is basically the official, upstream recommended version of the 0.10 series then distros can rest easy in updating 0.10.0 to 0.10.1 in a stable distro. This wont always work if the distro is too strict but it's still a generally sensible approach to versioning. So, what do you think? Col 1. Only after the either David's or Pierre's patch for fixing tsched=0 mode is merged into s-q tho' :D -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ 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
* 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] [PATCH] Do not use tsched watermark if tsched is disabled
2010-08-18 19:19, pl bossart skrev: * 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. Haven't tested, but I feel quite certain that it's the same one. 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. Assuming your reasoning is correct (I'm not that deep into DMA yet), this should be fixed in the kernel - by not allowing rewinds further back than 128 (or 256) bytes ahead of actual position. You say HDA can transfer up to 128 bytes in advance, but what about all the other drivers? Could there be other drivers having a lot larger DMA fetches? 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. So your idea is to prevent DMA transfers being modified, but I'm thinking of the maximum duration between the rewind and the point it gets filled up again by PA - all of that time we risc getting an XRUN because there is nothing in the buffer. And so I assume that the duration is never longer than 20 ms. I don't think it is much of a deal though. Rewind is not something used every second or so (or at least, shouldn't be). -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic ___ 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
On Wed, 2010-08-18 at 22:55 +0200, David Henningsson wrote: 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. Assuming your reasoning is correct (I'm not that deep into DMA yet), this should be fixed in the kernel - by not allowing rewinds further back than 128 (or 256) bytes ahead of actual position. You say HDA can transfer up to 128 bytes in advance, but what about all the other drivers? Could there be other drivers having a lot larger DMA fetches? What's the role of snd_pcm_rewindable()[1]? The documentation says Get safe count of frames which can be rewinded, which sounds to me like the function should always be called before snd_pcm_rewind(). Currently PA doesn't call _rewindable(). 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. So your idea is to prevent DMA transfers being modified, but I'm thinking of the maximum duration between the rewind and the point it gets filled up again by PA - all of that time we risc getting an XRUN because there is nothing in the buffer. And so I assume that the duration is never longer than 20 ms. I don't think it is much of a deal though. Rewind is not something used every second or so (or at least, shouldn't be). A comment on the last statement: I don't think the average frequency of rewinds is important, because there are cases where multiple rewinds do happen really quickly - for example when dragging a volume slider (IIRC pavucontrol ratelimits the volume change events to minimum of 100ms between each event sent to the daemon - that's still ten times a second). I don't remember hearing complaints about that the volume is crackling when changing volumes, but at least in theory this seems like a possible problem with the current implementation. [1] http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m.html#g8f56faf60ea6b60839e131df88f080d7 -- Tanu Kaskinen ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
