Hi, however, there is at least one (not really commercially available) sound card which utilizes the USB2 bandwidth, but being conform to the Linux USB sound driver without any modification. This is a custom made deivce for use with hearing aid shells, see http://lad.linuxaudio.org/events/2009_cdm/Friday/07_Grimm/07.pdf for a description. In its full configuration it provides six input channels and two outputs, at 24bit/96kHz, resulting in 13500 kBit/s capture bandwidth, and 4500 kBit/s playback bandwidth. At least the input bit rate is above the USB 1.1 specification. Not to useful information, just a proof that it is possible to have USB2 sound devices which are Linux snd_usb compatible. Giso Paul Davis wrote:

Lorenzo wrote: there are some excellent and very well-supported firewire devices out there. personally, i've been using the saffire pro26 and the mackie onyx 16ch mixer - both work very well on a properly tuned system. both would qualify as "expensive", though, even though price/performance is more than adequate.

On Thursday 05 November 2009 23:40:43 Hartmut Noack wrote: I was going to recommend the edirol um22 like I own one. But then again you are probably searching for a usb-audio interface ;-) Lets face it: in the 50€ range there is nothing to expect except for behringer and maybe terratec. Both cheap and noisy as hell. And not really better then any built-in sound-card. Arnold

On Friday 06 of November 2009 19:55:25 Martin Homuth-Rosemann wrote: Hi Martin, How do you "add" a REG103-A? Do I need a deep knowledge of electronics, or would a soldering iron be enough? ;) I've got a UCA202 which causes a very audible, pulsating noise at multiples of 1 kHz while running Jack. If there's a way to fix it, I'd like to try. Of course the device was cheap, and as it is it's pretty much useless to me, so I'm not all too afraid of breaking it... Dominic

Am Samstag, 7. November 2009 schrieb Dominic Sacré: Hi Dominic, if you compare figure 37 and 39 you'll see the difference. I've soldered the two resistors 27k and 13k and the diode D1 directly onto the IC1 (these 4 devices are SMD parts - I had to use a magnifying glass an a very fine pitch soldering iron) and made connections to pin 3, 10, 11 and 28 of pcm2902. This "piece of crap" is fixed with hot glue and I'm done. You can substitute the voltage regulator by any other low drop type - the enable input isn't imperative. The pcm2902 codec needs about 3.6..4.0 volts at pin 10 to override it's internal voltage source. Good luck. Ciao Martin

Hartmut Noack wrote: In which dimension? Would a longer low-profile card fit? If you can live with no more than two unbalanced input channels, the high-end (and -price) Xonar cards are much better than any USB(2) device. Best regards, Clemens

Ivica Ico Bukvic wrote: Yes. Best regards, Clemens

Jörn, Just in case you haven't noticed: Firewire is dead. The number of devices with a firewire port is decreasing rapidly. I wouldn't advocate Firewire devices anymore for new buyers. Flo -- Machines can do the work, so people have time to think. public key DA43FEF4 x-hkp://wwwkeys.eu.pgp.net

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Arnold Krille schrieb: And even if you only need the 2 channels USB1 can provide easily you wont find any USB1-Device on the shelf. The vendors build everything in USB2 - just because it is there and they don not want to discuss consumer-questions like "What?! USB1 only - and I shall pay more then 20 for such an antique piece of equipment?". So these big beasts seem to be the only alternative... I can only hope, that the distributors wake up and put some of their big-company-weight (and errrmm maybe some of their money?) into that. But they seem to be totally unaware of something like a need for pro-audio-support for Linux. - What a misconception! Every OS out there that qualifies as "full grown" offers support for everything any user today does on a PC. MS and Apple do not ignore audio-needs just because audio-producers are only a small percentage of the userbase. The SuseAG showed some insight on this as they put the alsa-people on their payroll and set up a certified-for-linux programme for multimedia-devices that made Linux visible to companies like Terratec. As a result we now have perfect support for envy24-cards. But NOVELL cut these efforts. And other distributors, that proudly claim "We love the desktop-user!"? They do not much more than to gracefully accept a halfhearted integration of the unpaid efforts of free devs in the backyards of their repos... I really wonder what can be done to change this...

On Sat, Nov 7, 2009 at 6:06 AM, Hartmut Noack <zettberlin(a)linuxuse.de> wrote: No, Apple (which is the only one of the two) just decides to drop firewire on its not-top-of-the-line machines, thus rendering the audio interface hardware already owned by thousands of people unusable on a new machine. Because "it doesn't matter" .... AFAIK, we had perfect support for envy24 cards before "certified for linux" ever existed. Are there specific things that you know which were added/improved/fixed because of the input of h/w vendors and/or the CFL program?

You are blaming the wrong people. Its soley the card manufactures not providing the necessary information. So, if they don't help, don't buy their products. Or you learn how USB2 is working and use some tools like usbspy or usbmonitor on XP/Vista to decipher the protocol your device uses and write a driver yourself. Since you won't do this, don't blame others if they don't do it as well. Best regards

On Sat, Nov 07, 2009 at 11:04:15AM +0100, Arnold Krille wrote: Well, yes, of course there are alternatives: run Windoze, which is what these bastards want to force us to do, isn't it? *sigh*. Haven't we already gone through this struggle before, with 3D video cards, and WiFi cards, and webcams, and input devices, just about every possible peice of computer hardware? In the last decade that I've been using Linux, I've seen this same problem come up again and again... and also seen it solved again and again. It's getting tedious, but, at the same time, it's not a new problem and since it's been solved before, there are ready answers and a suite of different solutions that have worked before, including: pressuring the manufacturers, reverse-engineering, NDIS/Wine, negotiations and payments, etc. Unless of course some enterprising hardware engineer wants to create an open-source, fully-documented USB2 audio interface, knowing they'd have a ready market in the couple dozen or so LAU members. Hmm, come to think of it, that might be an interesting project. Take apart a commercial, unsupported USB2 audio interface, see what chips they're using, look up the data sheets for those chips, and design an interface along similar lines, but open up the USB2 interface so that a Linux GPL driver can be written for it. These things can't be marvels of engineering amazingness: they're cheap, mass-produced products. Just off the top I'd be willing to bet that all of them use the exact same chipset, which does all the work anyway, and the products are different mostly in packaging and branding.

Ken Restivo: ... ... That could be an interesting project. but I can't do it alone. I have recently started a project to replace a plc: git-clone git://aspodata.se/openhw.git It is only a readme with some design thoughts for the moment. But what I say is that if we have a few HW-hackers that want to cooperate, I will gladly participate -- when I've finished the above project. What would the spec be? Regards, /Karl ----------------------------------------------------------------------- Karl Hammar Aspö Data karl(a)aspodata.se Lilla Aspö 148 Networks S-742 94 Östhammar +46 173 140 57 Computers Sweden +46 70 511 97 84 Consulting -----------------------------------------------------------------------

Folderol: ... Well, then you could design around a ft232 [1]. But would RS232 suffice for 8ch/24bit/44.1kHz (12Mbit/s) ? Shall I interpret your answer as the main hurdle is not to convert x channels at real time, but to get it into the computer? Would a network connection solve that problem? In that case the DACs and ADCs could reside on an embedded computer and stream the sound data to/from the pc. And one could envision such little things near each mic and ethernet cables or possible wifi to the control room. Power-Over-Ethernet [2] could be helpful, and why not throw in a pre-amp and plug it directly into the mic. Regards, /Karl [1] http://www.ftdichip.com/Products/FT232R.htm [2] http://en.wikipedia.org/wiki/Power_over_ethernet ----------------------------------------------------------------------- Karl Hammar Aspö Data karl(a)aspodata.se Lilla Aspö 148 Networks S-742 94 Östhammar +46 173 140 57 Computers Sweden +46 70 511 97 84 Consulting -----------------------------------------------------------------------

Folderol: ... ... Lets say we have pc <> switch <> lots of network boards for a single mic PC could broadcast the clock to all micboards and the would hopefully arrive without noticeable skew or jitter. And the micboards could answer with that timestamp and the converted value. In this case the PC requests each sample one at a time from all micboards. Would that be good scheme? A simple ping here, has a rund trip time of 0.25 to 0.8 ms depending on end equipment. Regards, /Karl ----------------------------------------------------------------------- Karl Hammar Aspö Data karl(a)aspodata.se Lilla Aspö 148 Networks S-742 94 Östhammar +46 173 140 57 Computers Sweden +46 70 511 97 84 Consulting -----------------------------------------------------------------------

Ken Restivo: ... ... Yes, or maybe raw ADC ints. My near future project will use AT91SAM9260 (arm9, 32bit, 200MHz), and linux. I don't know netjack nor osc, but maybe someone else does, would they be good, lightweigth, and easy to implement for this? Why not, maybe not cheeper, but open and hacker friendly. Well start from the top: 1, test netjack and osc if they are things to use (someone else has to come with the expertise for that) 2, the same with dummy audio values from the microcontroller to see if its performance holds, I have an evaluation board that one could do that on 3, the same add any ADC and an ext. preamp to get real sound 4, refine the ADC part to satisfaction 5, add preamp part 6, add power-over-ethernet so its just ONE cable 7a, start to miniturize, possible makeing it small enought to sit directly on the mic, or... 7b, add channels I could do steps 2, 3, possible 4, 6 and possible 7. Nice, don't you think so? And, since ethernet is driven through transformers we won't have any ground loops, etc. On the negative side is that ethernet cables are more stiff than microphone cables, they have the wrong color ... it woun't look that good, and they are not that durable, same with its connector, but there are industrial version ethernet connectors one could possible use with more suitable cables. Regards, /Karl ----------------------------------------------------------------------- Karl Hammar Aspö Data karl(a)aspodata.se Lilla Aspö 148 Networks S-742 94 Östhammar +46 173 140 57 Computers Sweden +46 70 511 97 84 Consulting -----------------------------------------------------------------------

Folderol: So we have two proposals: Plan A: netjack Plan B: raw ADC data, and let "master" pc take care of the rest Please look at git://aspodata.se/openhw.git, comments are welcome. ... Ok..., can you alborate on your point 2, I didn't get that part:) ... What, then, would the preliminary spec to aim to be ? Regards, /Karl ----------------------------------------------------------------------- Karl Hammar Aspö Data karl(a)aspodata.se Lilla Aspö 148 Networks S-742 94 Östhammar +46 173 140 57 Computers Sweden +46 70 511 97 84 Consulting -----------------------------------------------------------------------

Ken Restivo: ... ... I took a quick look at OSC [1] and NetJACK [2]. It would be good if we could made that happen. What will the hardware requirements for thoose be? OSC seems simple, but NetJACK? I suppose it will need an alsa driver? Regards, /Karl [1] http://opensoundcontrol.org/ [2] http://netjack.sourceforge.net/ ----------------------------------------------------------------------- Karl Hammar Aspö Data karl(a)aspodata.se Lilla Aspö 148 Networks S-742 94 Östhammar +46 173 140 57 Computers Sweden +46 70 511 97 84 Consulting -----------------------------------------------------------------------

On Wed, 2009-11-11 at 21:33 +0100, Giso Grimm wrote: Yes, that's a real problem. I don't see a solution to that either. I guess that jack is too big a burden for the small kind of system we are talking about, so the question is, if netjack could be implemented standalone - or maybe another suitable mechanism? / Hans

On Thu, 12 Nov 2009 09:11:48 +0100 Giso Grimm &lt;gg3137(a)vegri.net&gt; wrote: A little bit of interest maybe. It appears there is a software suite for the 'other' OSs that can manage 16 channels of 48k over the Internet (not just a LAN) provided you have an upstream of greater than 150Mbps and downstream better than 750Mbps. Also, there is a very useful looking fully self-contained Ethernet chip that can deliver 25Mbps at application level. This is the WIZnet W5000. It can also open up to 4 sockets, so I'm not clear as to whether that is 25Mbps per socket, or in total. Very empirically speaking, with 1 channel at 24 bit depth that's a potential sample rate of 1MHz, or putting it another way 20 channels of 48k! OK, OK, I know I'm leaving out huge swathes of control, collisions etc. :) This chip can handle both TCP and UDP. From what little I know of the protocols I would say that UDP would be the way to go. Everything listens to anything on the network, and all recognition and handshaking is done away from the network connection itself. This is bound to reduce latency as well as reducing packet size. Being a bit simplistic if you have a master clock (not necessarily the computer) send just a timecode at 48kHz everything can lock on to this immediately, and keep updating its copy of the timecode. Something wanting to transmit audio would then send back it's own ID, the current timecode followed by up to 24bits of A/D stream. Packets would be small and latency low, buffer size could probably also be quite small. The computer would pick up all the incoming data streams and sort them into their appropriate channels and time points. At this level, the occasional out of sequence packet could probably be put back into it's right place with only a relatively small additional buffer - well I hope so! This is all off the top of my head, so I won't be at all offended if someone points out a simple flaw that brings the whole idea crashing to the ground. -- 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.

Giso Grimm: ... I don't understand this figure. From what I understand, jack talks with an alsa driver which talks to hw. And jackd -dnet talks with another jackd on the "other" box, which talks with its alsadriver/hw. Should I interpret this as jackd <==> alsa_special_netw_driver <= over the network => alsa_sp_driver <==> OSHw or jackd <==> special jack client <== over the network => other half of the special jack client, poss. incl. alsa driver <=> OSHw ? How come the OSHw have an audio transport between each other, or do you mean clock transport? Why not wait and se what the netjack people comes up with. My problem is to have "any" hardware up and running. And if the netjack crew solves the problem in the meantime, so much the better, and if not, then we have something to debug on. Regards, /Karl ----------------------------------------------------------------------- Karl Hammar Aspö Data karl(a)aspodata.se Lilla Aspö 148 Networks S-742 94 Östhammar +46 173 140 57 Computers Sweden +46 70 511 97 84 Consulting -----------------------------------------------------------------------

Karl Hammar wrote: You can get much better performance than that. It is defined in AES-3. Flo -- Machines can do the work, so people have time to think. public key DA43FEF4 x-hkp://wwwkeys.eu.pgp.net

On Wed, 11 Nov 2009 23:30:08 +0100 (CET) karl(a)aspodata.se (Karl Hammar) wrote: Jitter, as such is a solvable problem. You use a phase locked loop with a long enough time constant (high division factor) to average out the jitter. Where you have semi-permanent connections this time constant can be quite long provided that all the slave oscillators are pretty stable, and the master is rock solid. An entire cycle of 48kHz is about 20 uS so jitter would have to be significantly less than that to avoid 'cogging'. -- 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.

FA: So..., as a first try it is better to do a multi channel card, than to do multiple single channel ones and try to make them sync ? Regards, /Karl ----------------------------------------------------------------------- Karl Hammar Aspö Data karl(a)aspodata.se Lilla Aspö 148 Networks S-742 94 Östhammar +46 173 140 57 Computers Sweden +46 70 511 97 84 Consulting -----------------------------------------------------------------------

-------- FA: Ok, I'll be back when I have something to debug... Regards, /Karl ----------------------------------------------------------------------- Karl Hammar Aspö Data karl(a)aspodata.se Lilla Aspö 148 Networks S-742 94 Östhammar +46 173 140 57 Computers Sweden +46 70 511 97 84 Consulting -----------------------------------------------------------------------

On Fri, 13 Nov 2009 14:57:51 +0100 (CET) karl(a)aspodata.se (Karl Hammar) wrote: I think it actually only needs to be less that 10uS The effect you can get with a system with poor stability but very strong locking when incoming pulses are half way between the wanted times (used to happen a lot with early discrete PLLs). The system will alternately lock on the early and late pulses. The correction waveform looks like a cog railway :) -- 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.

On Friday 13 November 2009 22:37:33 fons(a)kokkinizita.net wrote: Is this possible? Despite the fact that some operating systems don't provide that granularity, there is the outgoing network layers involved and the incoming layers on the receivers side. I don't think these are both with a delay constant enough to be usable as a timing source for a-d-conversion. Arnold

On Fri, 13 Nov 2009 22:37:33 +0100 fons(a)kokkinizita.net wrote: I fully appreciate what you are saying here. I have been largely thinking out loud, and also mostly in the digital domain where timing variations can be far more coarse-grained. The fact there is software out there that enables collaboration via the internet demonstrates that it is do-able. We just? need to think out how it can be done with as simple hardware as possible :) -- 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.

On Fri, 13 Nov 2009 23:42:31 +0100 fons(a)kokkinizita.net wrote: Ah! I wasn't aware of that. It's not a point that is exactly made obvious - I wonder why? OK. That makes sense. So our single multi-channel network soundcard should also provide the timing for the computer (rather like an internal soundcard does). This takes all, well most, of the precision out of the computer, which is something I like the idea of. With the appropriate network-jack driver (which would be hardware agnostic) it can be used with just about any machine. Looking up the AES spec quickly reveals 48kHz +/- 10ppm. If the card's master oscillator has that kind of stability, it would surely require only very tiny slow adjustments to keep two of them in sync. Worst case would be them consistently drifting the maximum allowance in opposite directions, which if my maths is up to scratch results in about a second before they would actually get out of step by 1 cycle. A quick google reveals 5ppm temp compensated oscillators with a a 7ppm voltage controlled pull-in - no idea how much these cost though. -- 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.

Folderol: ... Maybe the price can be found at http://www.arrownac.com/ Regards, /Karl ----------------------------------------------------------------------- Karl Hammar Aspö Data karl(a)aspodata.se Lilla Aspö 148 Networks S-742 94 Östhammar +46 173 140 57 Computers Sweden +46 70 511 97 84 Consulting -----------------------------------------------------------------------