On Thu, 15 Nov 2001, Anders Torger wrote:
> On Thursday 15 November 2001 23.13, you wrote:
> > latency.c probably should handle this case more gracefully. But the core
> > issue is: why doesn't the RME96 driver adjust buffer-size and period
> > properly? Are there hardware-constraints with the RME DIGI96 soundcard, or
> > is the driver somewhat custom tailored to your needs, Anders? Or is it an
> > API incompatibility of the evolving alsa-library with the driver?
> >
> > Is there a chance to get the driver into good shape? I'd be willing to
> > help...
>
> The hardware is limited to generate interrupts either at every 2048 bytes, or
> every 8192 bytes. There is no other setting. How many samples that is depends
> on the sample size (2 or 4 bytes) and how many channels (2 or 8). So, I don't
> think there is a bug in the buffer and period size setting.
>
> However, the hardware has no DMA, so the CPU needs to do the copying from the
> sound card memory to the host memory, which is done in the interrupt handler
> of the driver. This makes the card unsuitable for free-running memory-mapped
> mode, since the mapped host memory isn't updated until the interrupt is
> generated. This means that some programs using memory-mapped mode could get
> choppy sound using this driver. However, it could be fixed by a hack, which
> would not only copy in the interrupt handler, but also when the sample
> pointer is accessed, since one can assume that most free-running code will
> access the sample pointer before using the memory. I think it is quite an
> ugly hack, so I have not implemented it though.
It's not an ugly hack. It's a working solution, because the pointer
routine is always called from interrupt and when the user space
code requests the actual position. It is not allowed to an application
to write data directly without knowledge of the actual position. We have
already this code in the CS46XX and EMU10K1 raw PCM drivers - see
snd_cs46xx_*_transfer routines. It is also guaranteed that the samples are
copied only once when needed.
> I know of only one bug in the driver, where the sample rate indicator is not
> updated in some cases. Apart from that minor problem, it should be in very
> good shape, if not the APIs have changed recently (my 0.9 CVS is not the
> freshest).
APIs are almost stable without any major modifications.
Jaroslav
-----
Jaroslav Kysela <[EMAIL PROTECTED]>
SuSE Linux http://www.suse.com
ALSA project http://www.alsa-project.org
_______________________________________________
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
