Tom Browne wrote:
>
> I was not aware of the method which ALSA employed to generate the callback -
> I just expected it to _work_ like it does in Win9x (optimistic, it would
> appear). Okay, ALSA async is dodgy... I won't use that mode, then. But at
> least Jaroslav has fixed it so it doesn't c
> >Well, it doesn't seem to be completely okay... I occasionally get the
error
> >"Initial write error: broken pipe" and it just shuts down (well, it
actually
> >just hangs because the incallback mutex is never cleared - I need a
timeout
> >in there) the callback if things get too much for the poo
Hi,
I don't know wether this is for linux-kernel or for this list, so excuse
me if I am OT. The driver for my SoundblasterPCI128 did work up to
2.4.14 flawlessly. But with pre6 and pre8 all the modules are still
compiling and loading OK but sound has stopped completely. Even workbone
only star
>Well, it doesn't seem to be completely okay... I occasionally get the error
>"Initial write error: broken pipe" and it just shuts down (well, it actually
>just hangs because the incallback mutex is never cleared - I need a timeout
>in there) the callback if things get too much for the poor thing
> let me reiterate: you cannot safely call functions in alsa-lib from
> the SIGIO handler, because alsa lib makes repeated calls to functions
> that are not async safe. i also do not know the extent to which linux
> POSIX compliance ensures that even those functions that are supposed
> to async sa
Hello
I use ac3dec which comes with alsa as a very nice example on how to program
the alsa-lib for PCM out.
Is there a similar program showing how to use MMAP output ?
I would like to update the xine media player to use MMAP.
Cheers
James
--
Nothing in this world is exactly what it appears to b
>i suspect that you may not be writing chunks of the correct size to
>the PCM device. by delaying for 1000msecs when you have no idea what
sorry, i was forgetting what snd_pcm_wait() did. even so, this is
still a design that could cause problems, i think.
--p
__
>I am wanting to know wether there is some way I can get rid of these < 1ms
>XRuns ?
do note, hwoever, that it could easily be your application desing that
is the problem.
this:
>while ((frameCount=dd->audio.readAudio()) && dd->audio.active){
> int written;
>written=snd_pcm_writei
>I am wanting to know wether there is some way I can get rid of these < 1ms
>XRuns ?
if they are not caused by your application's design (i haven't looked
at it closely), then the answer is no, at least not without:
1) running it SCHED_FIFO, with mlockall() called
2) running a low-latency
Hi,
I am wanting to know wether there is some way I can get rid of these < 1ms
XRuns ?
I run an unmodded kernel with no latency patches.
Versions :
Advanced Linux Sound Architecture Driver Version 0.9.0beta8a.
Compiled on Oct 15 2001 for kernel 2.4.10 with versioned symbols.
I just changed my a
10 matches
Mail list logo
