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. 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). /Anders Torger _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
