On Sat, 2010-08-21 at 21:51 +0200, Ivar Mossin wrote:
So my questions are:
Is there a way to load both these cards without modifying the source?
This is a bug that should be fixed in the source. But you can work
around this by loading the failing card manually, just give it a unique
name in the
On Mon, 23 Aug 2010, Shouqun Liu wrote:
Hi Jyri,
I have applied the patch, but makes no effort to improve the performance,
the CPU usage is still high :)
Well, I originally created the patch to avoid pulseaudio getting stuck
while waiting swapped out memblocks on Nokia N900. After applying
'Twas brillig, and Tanu Kaskinen at 23/08/10 07:31 did gyre and gimble:
So, how to fix the bug? I'd just add a new module argument for
module-alsa-card: namereg_fail. It could be used by module-udev-detect
to override the normal logic for setting the flag.
Either that or just fix udev-detect
'Twas brillig, and Halim Sahin at 21/08/10 04:09 did gyre and gimble:
Hi Folks,
Taking exclusive soundhardware access is one of the most anoying
behaviour of pulseaudio.
One other problem is that the pa devs seem not wanting to help in any
place if the requested feature don't fit in their
On Sun, Aug 22, 2010 at 04:12:43PM +0200, Ivar Mossin wrote:
On Sun, Aug 22, 2010 at 2:52 AM, Daniel Mack dan...@caiaq.de wrote:
Can you post the output of lsusb -v with both cards connected?
Thanks,
Daniel
Daniel:
I'm not sure how the output of lsusb -v will help the issue as both
On Mon, Aug 23, 2010 at 02:10, Colin Guthrie gm...@colin.guthr.ie wrote:
If you really don't want to change anything in the pa design, simply
offer a
way that pa can prevented to take exclusive access to the soundhardware
by falling back to alsa's dmix.
No, that's not the right approach.
Recent NVIDIA GPUs include an audio controller that hosts a number of
different ALSA PCM objects. For example, consider the following output
from aplay -L:
hdmi:CARD=NVidia_1,DEV=0
HDA NVidia, NVIDIA HDMI
HDMI Audio Output
hdmi:CARD=NVidia_1,DEV=1
HDA NVidia, NVIDIA HDMI
HDMI
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
pl bossart wrote:
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
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
10 matches
Mail list logo
