On 05/15/2012 12:33 PM, Paul Davis wrote: The VSL1818 works OOTB with ALSA >= 1.0.24. http://linuxmusicians.com/viewtopic.php?f=6&t=7543

On Tue, May 15, 2012 at 12:40:34PM +0200, Robin Gareus wrote: Does that include configuration settings (sample rate, clock source, etc.) which are apparently only SW controlled ? 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)

On 05/15/2012 06:31 AM, Robin Gareus wrote: Please keep us updated! The best I've had an experience with has been the Edirol UA-101, regretfully no longer made. You have to manually change the sampling rate with a switch and power cycle it but it does work very well under linux. I'm also looking for an 8 channel USB2 soundcard. I have been trying out an Maudio Fast Track Ultra 8R but I can get it to work reliably below 256x2 and even then I see xruns from time to time (this under kernel 3.2.x-rt). So I can't recommend it. -- Fernando

2012/5/15 Fernando Lopez-Lezcano <nando(a)ccrma.stanford.edu>du>: If you haven't yet, retry with 3 periods/buf. -- E.R.

On Tue, May 15, 2012 at 2:03 PM, Clemens Ladisch <clemens(a)ladisch.de> wrote: sadly, this is not: http://www.solid-state-logic.com/news/hires/Nucleus_overhead_large.jpg despite being pretty new and only handling 4 channels

On Wed, May 16, 2012 at 5:28 AM, Robin Gareus <robin(a)gareus.org> wrote: No, no, their point is about the fact that it uses Mackie Control Protocol. Thanks to SSL I have totally revamped Ardour3's Mackie support and the surface itself works very, very, very nicely (especially with a direct ipMIDI connection into Ardour3's own ipMIDI support). What's a shame (and what makes the purchase price even more absurd for Linux users) is that they used a proprietary USB audio stack. I'm trying to see if I can wedge it open with some gentle banter :)

On 05/15/2012 08:03 PM, Clemens Ladisch wrote: [..snip..] All right. All systems go. `jackd S -d alsa -d hw:1 -p 64 -n2` works great! that's jackdmp 1.9.9 -- git f82ec715 Linux 3.2.0-2-rt-686-pae #1 SMP PREEMPT RT i686 on an Atom CPU dev-kit board: Genuine Intel(R) CPU @ 1.00GHz (!) running debian/wheezy (alsa/libasound 1.0.25-2). jack_lsp lists 18 inputs and 18 outputs (so SPDIF and analog I/O seem to work simultaneously, but I have not tested SPDIF I/O -- Brian was kind enough to patch analog output channels 1-8 to their respective inputs for me to runs some tests.) `mplayer | patch-cables | jack_capture -c 8` works fine and `jack_capture -c 18` does too, but the additional 10 channels are of course silent. `jack_delay` measured round-trip latency: 286.903 frames 5.977 ms 286.540 frames 5.970 ms 292.858 frames 6.101 ms 292.902 frames 6.102 ms 291.903 frames 6.081 ms 291.903 frames 6.081 ms 291.903 frames 6.081 ms 286.898 frames 5.977 ms 288.124 frames 6.003 ms Despite the slow system there were no x-runs. CPU utilization was around 70-80%. As for device configuration: jackd starts with either -r 48000, -r 44100, -r 96000 and -r 88200. The 1818VSL switches the sample-rate automatically. very neat! See attached `cat /proc/asound/VSL/stream0`. The clock-sources can be queried and set using `amixer` or `alsamixer`. The labels are somewhat misleading but that does not really matter: In `amixer` all names start with "AudioBox 1818 VSL Clock Selector" - even the Volume controls (but those end in "Playback V" and "Capture Vo"). `alsamixer` labels them "Front*2, Rear*2, Center, Woofer, Side*2, N/N*1, and then repeats that for 9 more channels (while in fact it's 8 analog + 2 SPDIF + 8 ADAT -- not sure about SPDIF/ADAT order), but that's just /usr/share/alsa/pcm/* trying to be smart. With -r96000 the device only worked with -p256 -n2 or larger periods - due to CPU limitation (-r 96000 -p128 or -p64 maxed out this weak CPU) `jackd -S -d alsa -d hw:1 -p 256 -n2 -r 96000` measured round-trip latency: 887.173 frames ~ 9.241 ms -- not bad! ..but I'll happily stick with 48k. FWIW. the device also runs fine with -p 32 !! `jackd -S -d alsa -d hw:1 -p 32 -n2` jack_capture recorded merrily w/o xruns, but jack_delay maxed out the CPU and caused xruns on this dev-board. Many thanks to Brian Quandt for making these tests possible. attached. since this ML limits emails to 30K, files are bziped: #lsusb -v 1818vsl/1818vsl.lsusb #amixer -c 1 contents 1818vsl/1818vsl.amixer.contents #amixer -c 1 controls 1818vsl/1818vsl.amixer.controls #cat /proc/asound/VSL/stream0 while running at 44.1 and 48k 1818vsl/1818vsl.asound-44100 1818vsl/1818vsl.asound-48000 I'm going to order one now :) robin

On 05/15/2012 06:10 PM, Fons Adriaensen wrote: Excuse my newbie question, but I'm not experienced with SPDIF. Can one [word-clock] sync two devices using SPDIF or ADAT and still use the analog I/O on both? -- Is that hardware specific or is there a standard for that? I assume the master-device will need to send a signal via SPDIF. I'll check later if the 1818VSL can do both: output to SPDIF and analog at the same time. but I don't know if I can do that remotely. What I do already know is that the clock-source for each input can be configured individually. but I'm still waiting for Brian to connect the device. my ssh login already works.. Here it mainly concerns the outputs: In my case there's a ground loop between my Screen (Asus VE278) and the active speakers when connected via computer and an USB UA-25 (not UA25-ex which features a ground-lift switch) -> 1/4inch TRS -> B2031A speakers. Disconnecting either the screen or the speakers (and using headphones) works, otherwise there's a hum on the system; luckily no sparks, no x-runs, either :) A multimeter shows a constant 1mA current and ~3-4mV AC potential. (measured between the USB-shielding of the PC and the disconnected USB-cable of the UA25) when the screen is connected. Both the screen as well as the speakers (and computer) are connected to the same power-stripe and share the ground. Fun-fact: When disconnecting the screen the potential between USB and PC goes up to ~150mV (IFF the computer is not battery powered otherwise it's 0) but the current drops to nil. /me is pondering to cut the ground-wire from the screen.. but I have so far refrained from doing that. Anyway at some point the interface may end up on stage somewhere and ground-lifting may be required for the inputs, too. Although in that case I'll likely have some ground-lifting DI-boxes around. robin

On 05/15/2012 10:59 PM, Fons Adriaensen wrote: They were not measure simultaneously. I first measured the voltage and _then_ the current. In both cases the device was not directly connected: I measured between USB-plug and socket shield. I expect that the voltage potential drops to near zero when I measure the current, but I have no way of verifying this (I don't have a 2nd multimeter at hand). Thanks for getting back to me about this nevertheless. Screen <-VGA-> Laptop (TP X60s) <-USB-> UA-25 <-TRS/jack-> Speaker(s) All devices are connected to one power-strip (except the UA25 which takes power from USB). To take one more thing out of the equation, I run the computer on battery. So it's Screen vs. Speaker. The screen has a switching power supply, but the speaker has a hardwired one (230V fixed). Any suggestions before I add a switch to the ground of the screen? bzzzzzzt, robin

On 05/16/2012 11:22 AM, Fons Adriaensen wrote: You know what?! that works!! thanks a bunch, robin