On Mon, 25 Mar 2002, Paul Davis wrote:
> >Well, if I am running capture and playback channels in sync, I certainly
> >don't want to restart the capture channel (and destroy my recording) in the
> >case when the playback buffer under-runs. Keep in mind I have a very short
> >buffer for playback (t
>Well, if I am running capture and playback channels in sync, I certainly
>don't want to restart the capture channel (and destroy my recording) in the
>case when the playback buffer under-runs. Keep in mind I have a very short
>buffer for playback (to keep latency down) but a long buffer for captu
> > > 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
>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
14 matches
Mail list logo
