On Fri, Feb 20, 2004, Takashi Iwai wrote:
> > Going back to the old ALSA tree from 2.6.2 'solves' the problem. I am
> > not experiencing the gstreamer lock, nor the interuptions in other
> > programs' playout.
>
> ok then please feed this to bugtracking system.
> provide the contents of files in /
On Thu, Feb 19, 2004, Takashi Iwai wrote:
> > Since I moved from linux-2.6.2 to linux-2.6.3-rc2, and then 2.6.3, I am
> > experiencing a strange problem with all the GStreamer applications: as
> > soon as GStreamer tries to play out a sound, the system gets extremely
> > slow, and no sound comes ou
Hi,
Since I moved from linux-2.6.2 to linux-2.6.3-rc2, and then 2.6.3, I am
experiencing a strange problem with all the GStreamer applications: as
soon as GStreamer tries to play out a sound, the system gets extremely
Hi,
since I moved from test3 to test9 (test8 would not recognize my usb
headset), I am experiencing a hang in ALSA playback almost everytime I
use my USB headset (Plantronics). In the syslog, I get something like:
Nov 6 15:00:09 naboo kernel: Debug: sleeping function called from
invalid context
On Tue, Oct 21, 2003, Jaroslav Kysela wrote:
> For a voice IP applications, it probably make sense to work without over
> and underrun detection (yes, if CPU is busy, there will be some scratches,
> but you'll avoid resyncing). Simply set stop_threshold to boundary for
> the no-xrun detection.
Tha
On Mon, Oct 20, 2003, Paul Davis wrote:
> the output latency is always roughly the size of the hardware
> buffer. there is no way to avoid this. the best you could ever do
> would be one period, where there are two periods per buffer (i.e half
> the buffer size). when i say "the best you could do",
Hi,
I am trying to build an application using ALSA, and which requires low
playback delays.
My first idea was to have a small hardware buffer to limit the playout
delays. But then if for some reason the buffer gets full, the card stops,
and the next writei will block for about one second.
My sec
