Re: [proaudio] Real-Time for audio playback?

[Mark Knecht <markknecht@xxxxxxxxx>]

On Thu, Dec 31, 2009 at 8:10 AM, Grant <emailgrant@xxxxxxxxx> wrote:
>>>> <SNIP>
>>> How would you configure a system for the absolute lowest jitter for
>>> audio playback?  Maybe nothing can be done besides choosing a
>>> low-jitter sound card and a playback app which uses a large buffer?
>>>
>>
>> You've got it right. Good quality equipment is where you start. Using
>> Jack allows you to monitor whether the buffers ever run dry. Smaller
>> buffers equate to lower latency but have nothing to do with jitter. If
>> I was going to purchase hardware I would look for two main
>> characteristics in semi-pro and above solutions:
>>
>> 1) DAC external to the PC - keeps internal PC electrical noise from
>> effecting the D/A conversion. Technically your USB device meets this
>> requirement.
>>
>> 2) Sound cards with a clock input - they all have crystals, but if you
>> can drive the device with a Word Clock or ADAT clock you can get much
>> lower jitter - basically as good as you want to pay for. Check out RME
>> cards for some great solutions in this area, but also ProSonus and
>> lots of other studio level companies now have semi-pro/consumer
>> devices that have these features.
>>
>> Of course, getting the best possible D/A chip inside your device helps also...
>>
>> One other thing you might want to explore as you investigate the
>> rt-sources kernel is that *disk* latency can actually be worse unless
>> you grant your audio driver higher priority than default. For
>> recording I use 1394 audio drives, not because they are faster (they
>> are) but because I know that the only data on them is audio and they
>> have their own driver in the Linux stack. I can grant the 1394 driver
>> higher RT priority and know that it will have no effect on system
>> operation in general. That way things like swap space access (yuck...)
>> and cron jobs, etc., don't get in the way of me moving data on and off
>> disk.
>
> Can there exist small time inconsistencies (latencies?) throughout the
> streaming of the buffer to the USB DAC?
>
> I'm just trying to root out any possibilities for improvement in Linux
> as a digital audio player.  Even the choice of USB cable is said to
> make an audible difference.  This type of thing can descend into
> paranoia pretty easily, but I want to press on.
>
> - Grant

Not if it's designed correctly. All audio timing is controlled by the card.

In the external sound card you have some sort of a buffer. It's large
enough to handle whatever the latencies are in the system to keep it
from running dry. Let's say the buffer is 1K deep and the sound card
requests data (in let's say) 128 bytes chunks (1 block) across the USB
bus. When you want to start playing audio the ALSA driver sends enough
data to fill the device's buffer and then the sound card starts
playing the audio. As it plays the buffer is drained. When the buffer
has 128 empty locations the sound card flags that it can handle
another 128 bytes so the ALSA driver sends it, but the card still has
1024-128 bytes waiting to be played. As long as the new data can be
delivered faster than it's being played then the buffer stays (mostly)
filled. As long as the buffer doesn't run empty the sound is produced
'perfectly'.

The only place the kernel latency effects this process is if something
happens that allows the buffer to run dry. The buffer can get as low
as 1 byte and the sound is still perfect. If new data arrives in time
then it continues to be perfect. It doesn't matter whether we use a
rt-kernel or a vanilla kernel. If the buffer doesn't run dry the audio
is 'perfect'.

Where the rt-kernel helps is that when the sound card asks for data
there should be a much lower 'latency' from the sound card raising a
hardware flag to the ALSA driver requesting data to the kernel
supplying this data to the ALSA driver sending it out to the card.
Lower latency in the rt-kernel helps the buffer not run dry, but the
truth is that the audio is identical and all that matters is that the
buffer not run dry.

Assuming you build an rt-kernel then the other thing you have to look
at is how you set real-time priorities. ALSA drivers don't just run
real-time because it's an rt-kernel. You have to configure WHAT you
want to run RT and at what priority.

Note that the 24-bit/16-bit problem you are trying to solve really
doesn't have anything to do with this specific problem. That seems to
be more about either what the card supports or what the ALSA driver
thinks it supports. That problem *may* be solvable in the driver. Even
if the card doesn't actually support 16-bit audio the driver could
fool the application by accepting 16-bit data and reformatting it with
8 extra bits, and then send that to the card as 24-bit audio. It
doesn't change the actual audio, just uses more bandwidth on the USB
bus.

Hope this helps. Ask more questions if need be.

Cheers,
Mark