Issue with RME HDSPe AIO latency

Issue with RME HDSPe AIO latency

[jamesm]

Hello all,

I'm using the RME hdspm kernel module with a Hammerfall HDSPe AIO card. 
I'm on RHEL 5.5, with alsa 1.0.17, kernel 2.6.18-194.11.4.

I have backported the latest alsa hdspm code to this kernel, as there 
were a number of bugs in the one that ships with the 2.6.18-194 kernel. 
I've also implemented support for copy() and silence() functions so that 
the hdspm driver can be used with applications via the RDWR interface 
instead of just MMAP (ie it just works with aplay without using plughw 
first.)

The latest hdspm driver code from alsa and kernel.org indicates that 
the HDSPe AIO card has a fixed buffer size of 16384. I've chosen a 
period size of 1024, which gives me 16 periods.

The issue I have is that whenever I play audio through the hdspm 
driver, the delay between the hw pointer and sw pointer is always close 
to the maximum buffer size (approx 16000). This leaves me with a large 
delay between writing data into the PCM and it coming out of the card. 
I'd like this to be between 1024 and 2048, I could probably crank the 
period down further to 512.

My application sets the start_threshold to 0 and avail_min to one 
period (1024). It then runs a thread, constantly writing data to the PCM 
(silence or real data).

Does anyone have any suggestions as to why the hdspm driver hw pointer 
is not following the application pointer more closely?

Is it due to the number of periods? Unfortunately I can't change that 
as the AIO buffer size is fixed.

Here are my pcm hwparams, swparams and status from /proc/asound when my 
app is running:

$ cat /proc/asound/card0/pcm0p/info
card: 0
device: 0
subdevice: 0
stream: PLAYBACK
id: RME AIO
name: RME AIO
subname: subdevice #0
class: 0
subclass: 0
subdevices_count: 1
subdevices_avail: 0

$ cat /proc/asound/card0/pcm0p/sub0/hw_params
access: RW_NONINTERLEAVED
format: S32_LE
subformat: STD
channels: 16
rate: 48000 (48000/1)
period_size: 1024
buffer_size: 16384
tick_time: 1000

$ cat /proc/asound/card0/pcm0p/sub0/sw_params
tstamp_mode: NONE
period_step: 1
sleep_min: 0
avail_min: 1024
xfer_align: 1
start_threshold: 0
stop_threshold: 18446744073709551615
silence_threshold: 0
silence_size: 0
boundary: 4611686018427387904

$ cat /proc/asound/card0/pcm0p/sub0/status
state: RUNNING
trigger_time: 1335799965.972782000
tstamp      : 1335801526.687332000
delay       : 15664
avail       : 720
avail_max   : 1056
-----
hw_ptr      : 74911440
appl_ptr    : 74927104

Regards
James Milne
FilmLight Ltd.

Re: Issue with RME HDSPe AIO latency

[Adrian Knoth]

On 04/30/2012 06:03 PM, jamesm wrote:

> Hello all,

Hi!

> The latest hdspm driver code from alsa and kernel.org indicates that
> the HDSPe AIO card has a fixed buffer size of 16384. I've chosen a
> period size of 1024, which gives me 16 periods.

Exactly.

> The issue I have is that whenever I play audio through the hdspm
> driver, the delay between the hw pointer and sw pointer is always close
> to the maximum buffer size (approx 16000). This leaves me with a large
> delay between writing data into the PCM and it coming out of the card.
> I'd like this to be between 1024 and 2048, I could probably crank the
> period down further to 512.

I suggest to try jackd1 and see if you can achieve the desired latency.
There's a tool jack_iodelay that helps you to measure the round trip
latency.

If it works, have a look at the code in drivers/alsa/ how jackd
configures the device.

I don't know what happened in alsa-lib between 1.0.17 and 1.0.25 wrt to
PCM streams, so if in doubt, update that library, too, maybe on a
different system if you don't want to touch your RHEL-5.5 installation.

> Does anyone have any suggestions as to why the hdspm driver hw pointer
> is not following the application pointer more closely?

The hw pointer is the hw pointer, it's the hardware, not the driver.
The hardware just cycles through its 16k sample buffer, so it's up to
the software (read: alsa-lib and/or application) to write to the
appropriate address.

It works just fine here on my RayDAT (also has a 16k sample buffer) down
to 32 samples per period via the MMAP interface.


Cheers

Re: Issue with RME HDSPe AIO latency

[James Milne]

Hi Adrian,

Thanks for the reply. In the end it transpired our code was always trying to keep the buffers full, but that meant it was 16384 samples ahead of the hardware pointer. There was another bug which meant this delay wasn't taken into account when filling the buffers.

I've changed it to keep the delay to a minimum by using snd_pcm_update_avail() to calculate how full the buffers are and only update them once they cross a certain threshold. This works fine.

Cheers
James Milne
FilmLight Ltd

On 7 May 2012, at 17:32, Adrian Knoth <adi@drcomp.erfurt.thur.de> wrote:

> On 04/30/2012 06:03 PM, jamesm wrote:
> 
>> Hello all,
> 
> Hi!
> 
>> The latest hdspm driver code from alsa and kernel.org indicates that
>> the HDSPe AIO card has a fixed buffer size of 16384. I've chosen a
>> period size of 1024, which gives me 16 periods.
> 
> Exactly.
> 
>> The issue I have is that whenever I play audio through the hdspm
>> driver, the delay between the hw pointer and sw pointer is always close
>> to the maximum buffer size (approx 16000). This leaves me with a large
>> delay between writing data into the PCM and it coming out of the card.
>> I'd like this to be between 1024 and 2048, I could probably crank the
>> period down further to 512.
> 
> I suggest to try jackd1 and see if you can achieve the desired latency.
> There's a tool jack_iodelay that helps you to measure the round trip
> latency.
> 
> If it works, have a look at the code in drivers/alsa/ how jackd
> configures the device.
> 
> I don't know what happened in alsa-lib between 1.0.17 and 1.0.25 wrt to
> PCM streams, so if in doubt, update that library, too, maybe on a
> different system if you don't want to touch your RHEL-5.5 installation.
> 
>> Does anyone have any suggestions as to why the hdspm driver hw pointer
>> is not following the application pointer more closely?
> 
> The hw pointer is the hw pointer, it's the hardware, not the driver.
> The hardware just cycles through its 16k sample buffer, so it's up to
> the software (read: alsa-lib and/or application) to write to the
> appropriate address.
> 
> It works just fine here on my RayDAT (also has a 16k sample buffer) down
> to 32 samples per period via the MMAP interface.
> 
> 
> Cheers
>