Re: [LAD] RME madi latency

On Sat, Feb 06, 2016 at 12:20:38PM +0100, Fokke de Jong wrote: > That, helped thanks. > Unfortunately I’m still getting the same huge latency as before.. Looks like a driver problem then... Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream,

Re: [LAD] RME madi latency

On Wed, Feb 03, 2016 at 10:41:06PM +0100, Markus Seeber wrote: > The buffersize can confuse applications which assume, that the > buffersize is variable and is always (buffersize = framesize * periods) > but I guess that this is not an assumption that should be made in the > first place.

Re: [LAD] RME madi latency

On Wed, Feb 03, 2016 at 10:41:06PM +0100, Markus Seeber wrote: > Was the driver already included in mainline? I saw the patch on > alsa-devel but kind of lost track of it. No. Takashi had some feedback, and I had neither the time nor hardware to work on it. I can do the cosmetics, but rewriting

Re: [LAD] RME madi latency

On Sat, Feb 06, 2016 at 04:12:39PM +, Fons Adriaensen wrote: > > That, helped thanks. > > Unfortunately I’m still getting the same huge latency as before.. > > Looks like a driver problem then... Not impossible, but I fail to see how. Here is the relevant driver side:

Re: [LAD] RME madi latency

On Sat, Feb 06, 2016 at 06:30:16PM +0100, Fokke de Jong wrote: > Ok, just to be clear: I *am* able to get the expected latency using jack > (around 3.5ms with a period=32 and nperiods=256). > but using my own alsa wrapper (and also using zita-alsa-pcmi) the latency is > >170ms You probably

Re: [LAD] RME madi latency

On 02/06/16 18:54, Fons Adriaensen wrote: Ok, just to be clear: I *am* able to get the expected latency using jack (around 3.5ms with a period=32 and nperiods=256). but using my own alsa wrapper (and also using zita-alsa-pcmi) the latency is >170ms You probably mean nperiods = 2 ??? Well,

Re: [LAD] RME madi latency

Ok, just to be clear: I *am* able to get the expected latency using jack (around 3.5ms with a period=32 and nperiods=256). but using my own alsa wrapper (and also using zita-alsa-pcmi) the latency is >170ms here’s the output from hw_params: Device: hw (type: HW) Access types: MMAP_COMPLEX

Re: [LAD] RME madi latency

That, helped thanks. Unfortunately I’m still getting the same huge latency as before.. cheers, Fokke > On Feb 4, 2016, at 21:51 , Fons Adriaensen wrote: > > On Thu, Feb 04, 2016 at 04:07:30PM +0100, Fokke de Jong wrote: > >> I tried the alsa_loopback example: >> >>

Re: [LAD] RME madi latency

On Thu, Feb 4, 2016 at 11:22 AM, Fokke de Jong wrote: > So now i am a but confused how to get the same kind of latency in my own code (using alsa directly rather than through jack) Are you coding ALSA yourself, or using a helper library? I can recommend Fons'

Re: [LAD] RME madi latency

It turns out I am doing something very wrong, and i *can* get much lower latency’s even with the large buffersize. I could not get jack_delay itself to work (it wouldn’t connect to any ports no matter what i tried), but i did use jack rather than my own alsa implementation and with a period

Re: [LAD] RME madi latency

I tried the alsa_loopback example: alsa_loopback hw:0,0 hw:0,0 48000 32 256 Can't open ALSA device which is weird, because i can open the device just fine, and so can jack… > On Feb 4, 2016, at 12:41 , Harry van Haaren wrote: > > On Thu, Feb 4, 2016 at 11:22 AM,

Re: [LAD] RME madi latency

If anyone knows how to get the roundtrip latency down, i would highly appreciate it! Ive pasted my full code below (the important stuff is in AlsaDevice::setParam and AlsaDevice::run_thread). The problem is that I only start getting input samples after o have already played an entire buffer

Re: [LAD] RME madi latency

> >> So now i am a but confused how to get the same kind of latency in my >> own code (using alsa directly rather than through jack) >> >> Basically what happens is when i have a buffersize of 8192 and a >> period of 32 is that snd_pcm_avail_update(capture_handle), will keep >> returning 0

Re: [LAD] RME madi latency

On Thu, Feb 04, 2016 at 04:07:30PM +0100, Fokke de Jong wrote: > I tried the alsa_loopback example: > > alsa_loopback hw:0,0 hw:0,0 48000 32 256 > Can't open ALSA device > which is weird, because i can open the device just fine, and so can jack… This is because maximum number of channels is

Re: [LAD] RME madi latency

Hi Adrian, I could’ve guessed you were on this list as well :-) I’m going to try this tomorrow when back in the studio, or maybe I can even do it remote if I have left everything patched up correctly :-) I will come back with the results. Thanks for your input! fokke > On Feb 3, 2016, at

Re: [LAD] RME madi latency

On 02/03/2016 03:40 PM, Jörn Nettingsmeier wrote: > On 02/03/2016 02:54 PM, Fokke de Jong wrote: >> Hi Adrian, >> >> I could’ve guessed you were on this list as well :-) >> I’m going to try this tomorrow when back in the studio, or maybe I can >> even do it remote if I have left everything

Re: [LAD] RME madi latency

On 02/03/16 14:04, Fokke de Jong wrote: Hi all, Hi! I have a RME madi fx card, but i found out that the minimal buffersize for those cards is 8192 samples, which is way to big for my use. Hardware buffer size. This buffer is divided into sub-buffers (periods) depending on what you

Re: [LAD] RME madi latency

On 02/03/2016 02:54 PM, Fokke de Jong wrote: Hi Adrian, I could’ve guessed you were on this list as well :-) I’m going to try this tomorrow when back in the studio, or maybe I can even do it remote if I have left everything patched up correctly :-) I will come back with the results. Thanks

[LAD] RME madi latency

Hi all, I have a RME madi fx card, but i found out that the minimal buffersize for those cards is 8192 samples, which is way to big for my use. So i am thinking of returning the card, and getting the ‘normal’ rme madi (without the fx). As that seems to have a more sensible minimal buffersize of