Mostra la font per a Maneres d'evitar la latència

__FORCETOC__
===Llista LAU 24 octubre 2008===
Re: Selecting Hardware for Music Production

Friday, October 24, 2008 3:13 PM

From: "Sean Edwards" <cybersean3000@yahoo.com>

To: ubuntu-studio-users@lists.ubuntu.com

<pre>
Devices that work with ALSA:
Unfortunately, the ALSA developers do not have the resources to test every device that appears on the market.  Really, there are three ways to check compatiblity: The ALSA site http://www.alsa-project.org ; look into mailing list archives post a question to a list, news group, or irc chat ; and lastly, buy something and see for yourself.

Mixers:
I use the Alesis 1622 in my studio.  I bought this new a very long time ago.

I use the TOA live, because it is a rackmount 10 channel mixer and takes up only 8 spaces in a rack.  I found both modules, the D-4 and D-4E, used on Craig's list for $50US.  It was local so was able to I try it out before buying it.

Behringer USB Devices:
The Behringer unit is actually a UCA202, sorry for the misspelling in my previous messages: http://www.behringer.com/UCA202/index.cfm?lang=ENG

The Behringer Guitar USB Interface, UCG 102: http://www.behringer.com/UCG102/index.cfm?lang=ENG

Other Behringer USB products:
http://www.behringer.com/02_products/computerbased_index.cfm?lang=ENG

You can usually find these Behringer devices on-line.  I usually purchase new from AmericanMusical.com, MusiciansFriend.com or zZounds.com.  I usually purchase used from Craig's list.  When it comes to used gear, I like to try before I buy.

Latency can be a problem and there are many many resources that explain the nature of the problem and how to deal with it.  One of the ways I deal with it is to do use external synths ( 2 Yamaha TX81Z's and an Alesis HR 16) to go into a mixer.  If I am using software synths on my PC (Timidity, ZynAddSubFX, FluidSynth, Hydrogen, etc.) in combination with rack mounted synths, I mix then all in the 1622 and record into the Mac with ecasound.

Another way to reduce latency is to not run a GUI environment like X Windows, and use a command-line utility for the project such as ecasound.  Other ways to reduce latency are to get the hardware as close to the CPU as possible which is why I sometimes use the PCI cards, you cant off-load the processing intensive Analog/Digital and Digital/Analog conversion from the CPU to dedicated hardware like the Behringer devices listed above, and you can build the project one track at a time (Drums, then Keyboards/Pad, the Bass, then Guitar, then Vocals, etc.).


If you have the resources to get the latency very low, you can combine MIDI sequencing, software synths, and audio recording into one utility like Rosegarden and do it all at once.

Figure out what it is you want to do, research how to do it, and then stay in your budget when making a purchase.  For example, I don't know for certain if a USB MIDI controller device, like one of the Behringer B-Control devices, can control the volume of a audio track in Rosegarden.  I am not going to make a purchasing decision until I have exhausted my research.

Above all else, do not forget Murphy's Law of Engineering: Every solution creates it's own set of problems

-=Sean Edwards=-
</pre>

===Llista LAU 12 desembre 2009===
<pre>
> Indeed. I think the ll (low latency) issue is of real importance when recording. At 64 
> ms multitrack recording/playback is a not very satisfying experience.

As long as you are recording sources that originate outside
the computer (i.e. soundcard inputs, either mics or instruments)
there *should* be no problem. The DAW needs to shift any 
material recorded while listening to existing tracks by
the round-trip latency, and for a punch in/out be a bit
clever with monitoring. All this can be automatic, and
if done correctly a player will *never* notice any delay.

Things get more hairy when using sources generated on the
PC. But then just playing them with 64ms latency is the
real problem.

Ciao,
</pre>

<pre>
On Fri, 11 Dec 2009, david wrote:

> Just wondering. Without an RT kernel here, my 2 laptops seem to run my 
> simple audio needs pretty well at 64msec latency. At least, it's never 
> bothered my playing along with computer-generated audio.

If your recording card can provide its own monitoring (M-Audio Delta and 
RME Hammerfall family both can), then for most things, your Jack latency 
doesn't seem to even matter.  I keep mine set to 21ms 99% of the time I 
use Jack, even though my system is very fast and stable, and is capable 
of running at *2ms* all day without xruns.  When the recording card is 
providing your monitoring, you basically have *zero* latency regardless 
of how your Jack settings are configured, and then it doesn't matter, 
because then you're in the wonderful world of hardware.  :)

Where it does start to matter is when you start using software-based 
sound sources, like LinuxSampler, or virtual synths.  Your recording 
card's monitoring can't help you much with that, and then you just need 
good enough latency to not end up feeling like you're hearing the output 
of what you're playing only after it's gone through a tape delay. 
Probably anything under 10ms is decent, but if you don't have some awful 
USB-based interface (which are a recipe for latency hell usually), you 
can probably do a lot better than even that.

> I see people on the list running much lower latencies than 64msec, and
> seemingly trying to get even lower ...

It does seem to be almost a competition sometimes...  Seriously, as some 
other people have pointed out once on here, you get a certain amount of 
natural latency in the acoustic world just from having a jazz group 
performing on a stage with some space between the players, since sound 
does take some time to travel, and the human ear can perceive *really* 
small timing differences in sound arrival timing as stereo position, 
distance, direction, and all that.  It still doesn't keep anyone from 
playing music on a stage though!  Any Jack latency under 10ms is really 
good.  I keep mine at 21ms when I'm working entirely with hardware 
monitoring and hardware musical instruments and effects (which is most 
of the time).  The Hammerfall/Multiface has its own hardware-based 
zero-latency monitoring and makes it not matter at all in that 
circumstance.
</pre>
==Explicació latència==
Aquí va una bona explicació sobre la latència, buffer, frames, periodes i XRuns. És una bona introducció a ALSA i a la programació de la llibreria asound amb C.

Introduction to Sound Programming with ALSA (http://www.linuxjournal.com/article/6735?page=0,1)

'''Sound Buffers and Data Transfer'''

A sound card has a hardware buffer that stores recorded samples. When the buffer is sufficiently full, it generates an interrupt. The kernel sound driver then uses direct memory access (DMA) to transfer samples to an application buffer in memory. Similarly, for playback, another application buffer is transferred from memory to the sound card's hardware buffer using DMA.

These hardware buffers are ring buffers, meaning the data wraps back to the start when the end of the buffer is reached. A pointer is maintained to keep track of the current positions in both the hardware buffer and the application buffer. Outside of the kernel, only the application buffer is of interest, so from here on we discuss only the application buffer.

The size of the buffer can be programmed by ALSA library calls. The buffer can be quite large, and transferring it in one operation could result in unacceptable delays, called latency. To solve this, ALSA splits the buffer up into a series of periods (called fragments in OSS/Free) and transfers the data in units of a period.

[[Imatge:6735f1.jpg]]

A period stores frames, each of which contains the samples captured at one point in time. For a stereo device, the frame would contain samples for two channels. Figure 1 illustrates the breakdown of a buffer into periods, frames and samples with some hypothetical values. Here, left and right channel information is stored alternately within a frame; this is called interleaved mode. A non-interleaved mode, where all the sample data for one channel is stored followed by the data for the next channel, also is supported.

'''Over and Under Run: XRuns'''

When a sound device is active, data is transferred continuously between the hardware and application buffers. In the case of data capture (recording), if the application does not read the data in the buffer rapidly enough, the circular buffer is overwritten with new data. The resulting data loss is known as overrun. During playback, if the application does not pass data into the buffer quickly enough, it becomes starved for data, resulting in an error called underrun. The ALSA documentation sometimes refers to both of these conditions using the term XRUN. Properly designed applications can minimize XRUN and recover if it occurs.

===Ara la meva explicació de la latència===
Per calcular la latència la fórmula és

<pre>
latència = (periodes * frames) / sample_rate
</pre>
Anem a veure com influeix cada factor en la latència.

'''Anem a suposar que estic tocant'''

M'interessa que la latència sigui baixa. Entenc per latència el temps que es triga a omplir el buffer, i que quan el buffer de l'aplicació client està ple l'envia ràpidament al buffer de la targeta de so. Per què ha de ser baixa? Doncs perquè si és alta es pot notar l'efecte entre que pitjo una tecla (per exemple utilitzo vkeybd com a client de JACK) i es produeix el so. (En el playback és important tenir la latència baixa).

Les mostres es guarden en els frames, i cada periode té varis frames (2, 3, 4,...). El buffer es divideix en N periodes, de manera que (mirar el dibuix) el producte periodes*frames em dóna el número total de frames que tinc en el buffer. (Fixem-nos que jo parlo de ''periodes'' i ''frames'', i que aquesta sintaxi és liosa si miro el que posa el QJackCtl.)

Per tenir la latència baixa interessa:
*reduir el número total de frames en el buffer (reduint els periodes o bé els frames per periode) (comprovar-ho en el QJackCtl)
*augmentar el sample_rate: com més ràpidament mostrejo més ràpidament omplo el buffer.

Ara bé, què passa si tinc una latència massa baixa? Doncs que puc tenir underruns: com que s'envia molt ràpidament el buffer de l'aplicació al buffer de la targeta de so, pot ser que encara s'estigui buidant i que ja es comenci a omplir de dades.

'''Anem a suposar que estic gravant'''

En les sessions de de gravació no és tan important tenir la latència baixa. El que sí que és important és no tenir XRUNs que comprometen la gravació. Per tant, és usual configurar una latència més alta.

Quan gravo s'omple el buffer de la targeta de so. Quan el buffer de l'aplicació està buit es genera una interrupció que diu: ''targeta de so, envia'm dades''. D'altra banda, hi ha l'aplicació que està gravant (un client de JACK, per exemple Ardour). Si aquesta aplicació no llegeix les dades prou ràpidament el buffer ja es torna a omplir i es perden dades: es produeix un overrun. Per tal que això no passi podem augmentar la latència. La única cosa que passarà és que el so no es grava en l'Ardour a temps real, sinó en diferit... però no passa res, la gravació no ha tingut XRUNs.

Com a resum, i per fer-se la idea didàctica, convé pensar en el flux de dades, qui genera les dades i qui se les menja. Tenim una aplicació client de JACK; el servidor JACK; i la targeta de so:
*playback: vkeybd > fluidsynth > JACK > targeta de so
*recording: targeta de so > JACK > Ardour

'''Nota''': i amb tota aquesta explicació ja entenc la sentència ''jack_set_process_callback (client, process, 0);'' que apareix en els codis que utiilitzen la API de JACK. Aquest callback significa que s'ha d'executar la funció ''process'' cada vegada que es requereixi. I es requereix cada vegada que tinc el buffer ple, quan es produeix la interrupció.