> > > Actually, I think I found the problem. I was using the maximum number
> > > of playback and captures channels reported by the device. For
> > > "plughw", this number is apparently 1, rather than the actual
> > > number the hardware supports! I guess what I have to do is open the
> > > "h
On Sun, 24 Mar 2002, Fernando Pablo Lopez-Lezcano wrote:
> On Sun, 24 Mar 2002, Ken McMillan wrote:
> > Actually, I think I found the problem. I was using the maximum number
> > of playback and captures channels reported by the device. For
> > "plughw", this number is apparently 1, rather tha
On Sun, 24 Mar 2002, Paul Davis wrote:
>
> >Actually, one more question that I couldn't answer from the API docs:
> >What do you have to do to recover from -EPIPE in the case when the
> >hardware doesn't stop (i.e., when stop_threshold == UINT_MAX)? Do you
> >just retry the write, or is there s
On Sun, 24 Mar 2002, Ken McMillan wrote:
> Actually, I think I found the problem. I was using the maximum number
> of playback and captures channels reported by the device. For
> "plughw", this number is apparently 1, rather than the actual
> number the hardware supports! I guess what I have t
> > Actually, I think I found the problem. I was using the maximum number
> > of playback and captures channels reported by the device. For
> > "plughw", this number is apparently 1, rather than the actual
> > number the hardware supports! I guess what I have to do is open the
> > "hw" device
On Sun, 24 Mar 2002, Ken McMillan wrote:
> Actually, I think I found the problem. I was using the maximum number
> of playback and captures channels reported by the device. For
> "plughw", this number is apparently 1, rather than the actual
> number the hardware supports! I guess what I have
>
>Actually, I think I found the problem. I was using the maximum number
>of playback and captures channels reported by the device. For
>"plughw", this number is apparently 1, rather than the actual
>number the hardware supports! I guess what I have to do is open the
>"hw" device first to get
Actually, I think I found the problem. I was using the maximum number
of playback and captures channels reported by the device. For
"plughw", this number is apparently 1, rather than the actual
number the hardware supports! I guess what I have to do is open the
"hw" device first to get the ac
>
>Oh -- thanks a lot for the quick answer! But then I guess I'll
>rephrase the question: Why would I get xruns with "plughw", but not
>with "hw"?
2 possibilities readily spring to mind:
1) the plughw device is causing more code to be run, possibly
causing timing issues
2) a bug in the
Oh -- thanks a lot for the quick answer! But then I guess I'll
rephrase the question: Why would I get xruns with "plughw", but not
with "hw"?
The -EPIPE occurs deterministically after 3584 frames (7 fragments)
are processed. I don't seem to get any -EPIPE errors with "hw".
Thanks -- Ken
I was having some trouble using the ALSA library called from within a
plugin. Apparently at some point libasound dlsym's itself, using a
null handle, which doesn't work if libasound is loaded as a dependency
of a dlopen'ed library (since its symbols are then not available to link
libraries agains
>1) The device "pcm.hw:0" seems to work fine, but when I use
>"pcm.plughw:0", I get "Broken pipe" from snd_pcm_writei. This happens
>even with stop_threshold set to UINT_MAX (i.e., this shouldn't
>be caused by underruns).
no, setting the stop threshold to this value just prevents the driver
from
I'm having a few problems with the 0.9beta11 drivers. Perhaps
someone has seen these before:
1) The device "pcm.hw:0" seems to work fine, but when I use
"pcm.plughw:0", I get "Broken pipe" from snd_pcm_writei. This happens
even with stop_threshold set to UINT_MAX (i.e., this shouldn't
be caused
Jaroslav Kysela wrote:
>
> > >(gdb) bt
> > >#0 0x4015e8d7 in snd_pcm_route_convert1_one () from /usr/lib/libasound.so.2
> > >#1 0x40cae5dc in ?? ()
> > >#2 0x012de908 in ?? ()
> > >Error accessing memory address 0xe8c1018b: No such process.
> > >(gdb)
>
> Can we see your code? The 32-bit form
On Sun, 24 Mar 2002 13:22:21 +0100
stef <[EMAIL PROTECTED]> wrote:
> Juan Linietsky wrote:
> >
> > Oh, and you know what, I was so concentrated in my hate for
> > sysex ;) that i just noticed that i forgot to write the most
> > obvious point about why sysex is a no-go.
> >
> > And this is basic
Juan Linietsky wrote:
>
> Oh, and you know what, I was so concentrated in my hate for
> sysex ;) that i just noticed that i forgot to write the most
> obvious point about why sysex is a no-go.
>
> And this is basically, that what you propose would work like this:
>
> sysex call to poll for bank
Juan Linietsky wrote:
>
> On Sun, 24 Mar 2002 01:35:18 +0100
> stef <[EMAIL PROTECTED]> wrote:
>
> > Nice idea, this could work for some preset synthesizers.
> > But it doesn't have to be part of Alsa.
>
> some preset synthetizers? not really. It would perfectly
> work for any soundcard with in
17 matches
Mail list logo
