Re: [LAD] Drivers for RME (USB) MADI device (Madiface XT)
On Mon, 11 Aug 2014 15:06:24 +0200 Adrian Knoth wrote: > On 08/11/14 05:47, D. Sen wrote: > > I was advised by Paul Davis to inquire on this list whether there has > > been or is likely to be any activity in developing ALSA drivers for the > > RME Madiface XT device. Its a USB device and as such makes it very > > amenable to a portable audio work. > > > > I have used PCIe based Madiface in the past using ALSA. However, I could > > not get the USB based Madiface XT to work. The device was recognized > > correctly (as per the SYSLOG) - however no drivers were loaded. > > > > Any help would be very much appreciated. > > As I said a year ago, it should also be possible to sniff the USB > connection, but this requires a device and a volunteer to do so. You'd > then run Windows in a VM and capture the USB packets with wireshark or > any other USB sniffer. > > Jonathan Woithe may have additional information, since he wrote the > drivers for FF400 and FF800. The FF400 and FF800 are, obviously, both firewire devices. Due to the bus structure and the way it operates there will be nothing in common between this and any of the RME USB or PCIe interfaces. The drivers for the FF400 and FF800 are in FFADO, and while you may get some high level ideas from things like our mixer interface, unfortunately our existing code is unlikely to provide much in the way of direct assistance when looking at devices using other interfaces. Having gone down the protocol analysis route before (albeit not on the RME devices) what Adrian has suggested is entirely feasible for the USB variant. It will be time consuming, but sniffing the USB bus isn't difficult technically speaking and - most importantly - doesn't require special hardware now we have VMs. Obviously the ideal situation is to obtain documentation from the manufacturers, so contacting them as Adrian suggested would be worth a shot. Regards jonathan ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Optimisations
On Mon, Aug 18, 2014 at 06:11:33PM +0100, Will Godfrey wrote: > A long time ago ... in a land far away :) > I did some assembler programming on the Acorn Archimedes (ARM 2/3) and worked > out a series of additions and subtractions that would perform very fast > multiplication of awkward numbers by known amounts. > > Is there any point in doing this for C programs, or are modern compilers > sophisticated enough to do such things themselves? > > If anyone is interested *7 is: > RSB R1, R0, R0, LSL #3 :-) Memories... I love ARM assembly... Modern compilers will do such things. If they exploit other features of the ARM (such as all instructions being conditional) I don't know, but it's very well possible. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Optimisations
On 08/18/2014 07:11 PM, Will Godfrey wrote:
A long time ago ... in a land far away :)
I did some assembler programming on the Acorn Archimedes (ARM 2/3) and worked
out a series of additions and subtractions that would perform very fast
multiplication of awkward numbers by known amounts.
Is there any point in doing this for C programs, or are modern compilers
sophisticated enough to do such things themselves?
If anyone is interested *7 is:
RSB R1, R0, R0, LSL #3
gcc 4.8 for ARM seems to give that instruction too with -O2 here for
a simple function that returns *7 of its input argument.
With no optimization:
:
0: e52db004push{fp}; (str fp, [sp, #-4]!)
4: e28db000add fp, sp, #0
8: e24dd00csub sp, sp, #12
c: e50b0008str r0, [fp, #-8]
10: e51b2008ldr r2, [fp, #-8]
14: e1a03002mov r3, r2
18: e1a03183lsl r3, r3, #3
1c: e0623003rsb r3, r2, r3
20: e1a3mov r0, r3
24: e24bd000sub sp, fp, #0
28: e49db004pop {fp}; (ldr fp, [sp], #4)
2c: e12fff1ebx lr
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] Optimisations
A long time ago ... in a land far away :) I did some assembler programming on the Acorn Archimedes (ARM 2/3) and worked out a series of additions and subtractions that would perform very fast multiplication of awkward numbers by known amounts. Is there any point in doing this for C programs, or are modern compilers sophisticated enough to do such things themselves? If anyone is interested *7 is: RSB R1, R0, R0, LSL #3 -- Will J Godfrey http://www.musically.me.uk Say you have a poem and I have a tune. Exchange them and we can both have a poem, a tune, and a song. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [LAU] Ardour MIDI tracer
On 08/18/2014 10:12 AM, Ralf Mardorf wrote: Qtractor the fader for synth plugins is pre everything ;), that's bad design, but I guess not the audio stream is controlled, but the synth volume. while on midi tracks, qtractor mixer/track faders simply deals midi channel volume (cc#7) and panning (cc#10) messages and that's from its birth model design (mainly due external/outboard midi h/w). iow. qtractor midi track faders doesn't deal or affect synth-generated audio signal whatsoever, at least directly--it all depends on each synth midi implementation, that is--so "pre" or "post-fader" conventions doesn't apply nor make much sense there. fwiw. all generated audio signal from synth/instrument plugins is routed to some (optional) audio output bus (default sink is "master"). and yes that will be the one true audio fader you probably should look when dealing midi instrument plugins audio output. remember that the qtractor mixer might NOT ever be the final stage of a mix; qtractor is not, never was, won't ever be, a monolithic solution :) hth. cheers -- rncbc aka Rui Nuno Capela rn...@rncbc.org ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [LAU] Ardour MIDI tracer
On Sun, Aug 17, 2014 at 06:34:25PM -0700, Len Ovens wrote: > I would think ((Gain+54)/64)*7f uses a lot less CPU time than a real > (proper) log. Think 8 fingers (plus thumbs?) fading around 80 steps in a > small time. Remember that this calculation has to be done at both ends too > and the receiving end also has to deal with doing more calculation on as > many as 64 tracks of low latency audio at the same time (amongst other > things). In the equation you mention, 'gain' is in dB, it doesn't make any sense otherwise. So after applying the inverse of that equation you need to convert from dB to a linear gain value. If M is the value sent by the controller (0..127) and G the gain in db then G = (64 * M / 127) - 54 which will be in the range -54..+10 dB. M = 0 is probably interpreted as 'off' instead of -54 dB as a special case. Step size is 64 / 127 dB or 0.504 dB. A slightly better mapping would be 80 step of 0.5 dB for the range +10...-30, then smoothly increase the step size to arrive at a minimum gain of -70 dB or so. Even for this the calculations are trivial. There is no problem with CPU use. On the sender side you transmit 0..127 which is just 7 bits of an ADC measuring the voltage from a linear fader or pot, there is no mapping at all. On the receiver side, the conversion needs to be done just once per 25 ms or so and only when the gain changes. Then interpolate linearly in between, or not at all if the value hasn't changed. The resulting CPU load is absolutely irrelevant compared to what has to be done anyway. As an example, my 4-band EQ LADSPA does this sort of calculations for each of its 13 parameters. And calculating the internal filter parameters is a bit more complicated than dB to linear. It makes no difference at all in CPU use which is dominated by the per-sample processing. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [LAU] Ardour MIDI tracer
On Mon, 2014-08-18 at 11:00 +0200, Ralf Mardorf wrote: > On Sun, 2014-08-17 at 17:44 -0700, Len Ovens wrote: > > On a DAW, we sort of do this already by recording using the fader (and > > audio device gain) for trim and then mixing down using the fader for fine > > tuning. However, as I commented earlier, sometimes a harsh effect can > > introduce the need to: > > - re-record the track > > - add a gain section after the effect(s) before the fader. This may be as > > simple as using the output level the effect already has. > > Indeed, digital mixing needs a learning curve that isn't needed for > analog mixing. An analog mixer provides a trim pot and an EQ, but no > effects for each channel, for effects there are inserts and pre and post > fader aux sends. Most people don't own analog mixers with automation. > Users of Linux DAWs should by default add and activate (even if it's > bypassed) FIL-plugin [1] for each channel. And care a little bit about > old school audio mixing. E.g what's the mind of using a compressor for > each channel and fading in and out and in and out during a song? > > All you need is FIL-plugins parametric EQ post effects, pre fader, not for Qtractor the fader for synth plugins is pre everything ;), that's bad design, but I guess not the audio stream is controlled, but the synth volume. For an anlog mixer this would be: Not using the fader of the mixer, but the synth volume for mixing, so you'll get 100% parasitic noise from effects, even if the synth volume is very low. Anyway, you want to build a remote control for digital mixers and can't care about wrong usage of good designed digital mixers and you can't care about bad designed digital mixers. -- http://iknowwhereyourcatlives.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [LAU] Ardour MIDI tracer
On Sun, 2014-08-17 at 17:44 -0700, Len Ovens wrote: > On a DAW, we sort of do this already by recording using the fader (and > audio device gain) for trim and then mixing down using the fader for fine > tuning. However, as I commented earlier, sometimes a harsh effect can > introduce the need to: > - re-record the track > - add a gain section after the effect(s) before the fader. This may be as > simple as using the output level the effect already has. Indeed, digital mixing needs a learning curve that isn't needed for analog mixing. An analog mixer provides a trim pot and an EQ, but no effects for each channel, for effects there are inserts and pre and post fader aux sends. Most people don't own analog mixers with automation. Users of Linux DAWs should by default add and activate (even if it's bypassed) FIL-plugin [1] for each channel. And care a little bit about old school audio mixing. E.g what's the mind of using a compressor for each channel and fading in and out and in and out during a song? All you need is FIL-plugins parametric EQ post effects, pre fader, not completely equal to an anlog mixer, but exactly what's needed and can be done for e.g. Qtractor's mixer. [1] "FIL-Plugins There's one plugin in this first release, a four-band parametric equaliser. Each section has an active/bypass switch, frequency, bandwidth and gain controls. There is also a global bypass switch and gain control. The 2nd order resonant filters are implemented using a Mitra-Regalia style lattice filter, which has the nice property of being stable even while parameters are being changed. All switches and controls are internally smoothed, so they can be used 'live' whithout any clicks or zipper noises. This should make this plugin a good candidate for use in systems that allow automation of plugin control ports, such as Ardour, or for stage use." - http://kokkinizita.linuxaudio.org/linuxaudio/ladspa/index.html -- http://iknowwhereyourcatlives.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [LAU] Ardour MIDI tracer
On Sun, 2014-08-17 at 08:24 -0700, Len Ovens wrote: On Sun, 17 Aug 2014, Ralf Mardorf wrote: > > > On Sat, 2014-08-16 at 09:45 -0700, Len Ovens wrote: > >> A quick thought on fineness of control. It is true that 127 levels > >> tends to "zipper". However, 127 levels is more than enough for static > >> levels. > > > > I disagree. I never heard zipper noise, when I fade in or out or when > > using MIDI panning. Usually those steps aren't audible when fading or > > panning, but I often missed steps for static levels. Speaking for synth > > from the 80th and 90th, for the panning synth usually didn't use all 128 > > values, but 128 steps usually are used for the volume. I don't remember > > audible steps when fading, but I remember that there were not enough > > steps for optimal mixing. YMMV! > > I don't know if it matters, but was that a linear fade or log? I don't know? On Sun, 2014-08-17 at 16:15 +, Fons Adriaensen wrote: > Suppose you have *real* faders which have a range of 127 mm. > That's not far from a typical size on a pro mixer. > Would you ever adjust them by half a millimeter ? Good point! As I already pointed out, I never noticed zipper noise when sending volume control to a synth, but sometimes 128 steps (and IIRC all 128 steps were used) were not enough. Perhaps it was neither linear nor log, but bad programmed usage of those steps. I remember that for panning often less then 10 steps were provided, I dislike/d this a lot. IIRC panning sometimes didn't effect a hold note, it was used for the next played note, so at least this can't be compared to a digital mixer. -- http://iknowwhereyourcatlives.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
