Put another way, it would be far more compatible if this were done over an IP stream rather than any native ethernet stream, not least it could use any ethernet driver that linux supports rather than a small subset of them. I am sure this will make a lot of the lower layer people turn away from the project which is unfortunate but there are a lot of issues associated with attempting to do this over a native ethernet connection: it would need some consideration to be given to data loss and recovery which are already native to the higher layers. Perhaps the project needs to be specified with regards to its goals? If the idea is just to have Ethernet supported as an interface then fine, native access is probably fine. If the idea is to have Ethernet supported as a transport the reusing what is already available makes a lot of sense. To start with, being able to use any Ethernet card already means it can be done cheaply. Limiting it to selected devices perhaps not so as it would require the purchase of specific cards. Anyway, to paraphrase a joke a friend made recently, he drove to a Linux Audio Conference where the people there said to him "what are those round things on the side of your car?". He said at least when we went to the networking conferences people knowingly said "ah, I know what _they_ are. They're called wheels..... I've seen those before." Kind regards, nick _________________________________________________________________ Windows Live: Friends get your Flickr, Yelp, and Digg updates when they e-mail you. http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/so…

Nick Copeland: Ack, a standard ip-stream is a sensible first choise. ... My goals is "just" to extend another project (industrial i/o). What would your goals be ? Shall we decide on a single mailing list ? 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 Tue, Nov 24, 2009 at 09:48:53AM +0100, Karl Hammar wrote: Like always: Analog parts are hard to build. You need to calibrate your circuits, you have tolerances in almost every component, you need a lot of knowledge to manufacture a high-quality ADC/DAC. This is stuff you could easily avoid if you just outsource the whole ADC/DAC to a company which has the skills to do this. Luckily, there's ADAT: eight channels of audio over a single, optical link. So all you would need is one or more ADAT jacks somehow attached to your computer. Even better: studios usually have ADAT-ADC/DAC around, they're only looking for a way to get the data from/to the computer. If you want to win the whole pro-audio scene for this project, just provide ADAT plugs. The cheapest ADAT ADC/DAC I know is the Behringer ADA8000: http://www.thomann.de/gb/behringer_ultragain_pro8_digital_ada8000.htm There is better gear around, e.g., the Apogee Rosetta converters or the RME ADI line: http://www.thomann.de/gb/apogee_rosetta_800_24192khz.htm http://www.thomann.de/gb/rme_adi_8_qsm.htm Don't get me wrong, but I guess you cannot match their level of quality. And I don't see why one should fiddle around with soldering some crappy analog ports when he has decent studio gear around or can buy good-enough quality like the Behringer ADA8000. And while we are at it: RME and Apogee often also don't even dare to provide a preamp, because the studio guys have better stuff around: http://www.thomann.de/gb/avalon_ad2022_preamp.htm The preamp makes the music. If you feed your 4000EUR Neumann M149 microphone into an Avalon, all you need is a decent A/D conversion and you're halfway done with your radio production. ;) Sometimes, these preamps come with builtin A/D converters. That's what I use: http://www.thomann.de/gb/focusrite_liquid_4_pre.htm See it? It reads "ADAT I/O". If the FOSS soundcard provides an IP-to-ADAT converter with zero latency mixing facilities and builtin DSP effects, you'd be the man! You could instantly sell numbers of units, it would be the perfect onstage mix/split/monitoring solution. Come on, we're talking about a new development here. New development should never ever focus on IPv4, IPv6 has been there since 1998. Manually assigning an IPv4 address feels so 1990s and increases complexity. With IPv6, you just put your device on the net and it gets a link-local address, that is, fe80:MAC-Address. (it's not exactly the MAC-Address, but it's derived from it). No need to assign anything, you're instantly ready to go. And you have link-local multicast (read: broadcast in IPv4 terminology). Just use an address starting with ff02 and send your streams to it. Everyone subscribed to this address would receive it. I have a jack client streaming/receiving IPv6 multicast streams. It's so easy. No configuration at all, I just fire up the application and I'm ready to stream. I don't even care about the other addresses used on this LAN. Let's talk about discovery: how do you intend to find your devices on the net? With IPv6 multicast, all soundcards could statically listen on ff02::dead:beef. Then, the workstation sends its discovery packet to ff02::dead:beef, all cards receive it and respond (connect back) to the source IP (or an IP given in the packet, but that's not even necessary) In other words: A single address is sufficient to trigger the callbacks. The cards tell the workstation about their very own IPv6 multicast streaming address, and the workstation simply has to tune in. There you go. Streaming and discovery within approx. 200 lines of code. Perhaps it's even a good idea to provide a master clock on an IPv6 multicast address, but clocks are a separate issue (in a studio, the workstation would probably slave to some decent specialised clock, e.g., Apogee Big Ben) [RockNet, Roland Digital Snake, Ethersound] Approximately what you could expect from a 100MBit/s link. At least 32 channels, rocknet even more, but they use 400MBit/s. Cheerio -- mail: adi(a)thur.de http://adi.thur.de PGP/GPG: key via keyserver

Karl Hammar wrote: What is wrong with netjack? It's made for point-to-point and very simple. You just have to solve the clock issue unless you want to lose bit transparency. Flo -- Machines can do the work, so people have time to think. public key DA43FEF4 x-hkp://wwwkeys.eu.pgp.net

On Tue, Nov 24, 2009 at 08:34:53PM +0100, Karl Hammar wrote: may i kindly ask what gave you that impression ? i admit that some jack versions in svn were broken for the LAN use-case because i am focussing on making it work for wireless and transcontinental internet connections. but the lan use-case it pretty trivial and doesnt need all this deadline machinery. if you just want to build a network soundcard, and use jack on a computer with that, its ready for 3 years now !!! having more than one network soundcard, and keeping stuff in sync is more tricky. it requires that you can control the wordclock on that soundcard, and you need a special version of alsa_out.c which instead of resampling controls the wordclock frequency. -- torben Hohn

On Thu, Nov 26, 2009 at 08:55:50AM +0000, Folderol wrote: :S great. did you try it, and it didnt work ? if you dont saturate the link, its one period. you have the same problem with usb soundcards. for 100Mbit the threshold where you need 2 periods, is somewhere around 12 channels. if you have a master clock, and want to adjust your output to this, then the alsa_out program would be what you want. it extracts the clock driving jackd, and is able to control a resampling rate so that the phase is pretty constant. i dont understand why you want that... alsa_out is able to deliver that. -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language

torbenh: ... ... "...but with that I would wait until there are decisions on the 'final' netjack version": http://lists.linuxaudio.org/pipermail/linux-audio-user/2009-November/064701… "Netjack also seems to have quite a high overhead, and no specific mechanism for RT syncing audio.": http://lists.linuxaudio.org/pipermail/linux-audio-user/2009-November/064792… ... Ok. Great, good news. Ok. let's start with ONE slave then. When that is working, then it's time for the sync part. So, this means that most of software part is more or less ready. We have OSC for control and netjack for transport. That means that I will forget about the software till I have some hw to test 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 -----------------------------------------------------------------------

On Tuesday 24 November 2009, Adrian Knoth wrote: Yes, but without those of us to whom a hot soldering iron is just as valuable a tool as the ubitiquous dual channel 100 mhz triggered, computerized scope is (I have both, and know well how to use them), all your ideas are just that, an abstraction that will wait for that hot soldering iron to bring it to life. Only then will you know what it will take and can write the software. That is why the enthusiasm on my part. Barring under influence by the Apples and Microsofts extant, a truly royalty free, available from off the shelf parts, interface really should replace the rest of these wanna be bus's as soon as the old stuff's limitations begin to be an artistic limit. That of course depends on the state of the individual studio, with some input from the tax and amortization schedules extant in that locale. Given a level playing field, something we all know the Apples and M$'s of the world abhor with all their considerable bank accounts and lawyers, this could be a working reality in 5 years, and dominant in 10. And the state of audio production would be considerably better off. Of course I'm preaching to the choir, but one has to start someplace. The more members the choir has, the louder they can sing. :) Don't have the ADAT, so I cannot begin to answer that in a sensible way. At what cost in ADAT capable boxes? Eggzactly. Lowest common denominator. Thanks for pointing that out. I think this might be the beginnings of _that_ discussion. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) The NRA is offering FREE Associate memberships to anyone who wants them. <https://www.nrahq.org/nrabonus/accept-membership.asp> I knew one thing: as soon as anyone said you didn't need a gun, you'd better take one along that worked. -- Raymond Chandler

On Tue, Nov 24, 2009 at 08:35:10PM +0100, Karl Hammar wrote: That's why I said "unless talking kernel level". The real difference with IPv6 is that you have plenty of addresses, so you don't have to abuse an RFC1918 network for a link local address. You just have one assigned from the kernel, that's all I've said. And when the kernel assigns and handles it, the app doesn't have to do it. Which reduces complexity. Which doesn't require an app to be able to set interface addresses (read: root permissions). Which is, to me, a good thing. YMMV. I'm happy to go away and not bother you with the progress network programming made during the last 10 years. Speaking of which: IPv4 already has this kind of link-local MAC-derived addressing: the DHCP fallback block 169.254/16, as specified in RFC3330. I know that this partially contradicts my argumentation, at least wrt to auto-assigned link-local addresses. I don't have to, the kernel already does it. That's all I've said. The added abstraction and address range makes it so easy for the application programmer. He doesn't have to care. And since programming for IPv6 gives you IPv4 for free (dual-use sockets), coding for IPv4-only clearly isn't beneficial. Of course, you are free to code whatever you want, but I don't see why one would focus on IPv4-only when he could get IPv6+IPv4 with modern code. (think of getaddrinfo() and getnameinfo(). Two functions, no need to know more). You are always free to ignore me. I just see so many code out there in the wild which has things like int ip_addr; inet_addr(); and the lot. Perfectly legal in the mid-90ties, but completely unportable wrt to IPv6. New code shouldn't do this anymore, hence the rude reflex. My apologies. -- mail: adi(a)thur.de http://adi.thur.de PGP/GPG: key via keyserver

Adrian Knoth: The world is not black and white. My only point was that for this application I see no real difference between IPv4 and IPv6. Yes, it occurred to me also (I always turns it off:). ... [ some ancient code ] If you promise not to let your rude reflex to show its ugly face again, I will accept your apology. That said, it does not mean I'm always right, and sometimes I'm more happy being wrong than right. Let's start over. ======= My position is to be able to run both ipv4 and/or ipv6 per user discretion. I don't think we have any disagreement about that. Also, my position on how to make and keep latency low, an easy first step is to make sure there is no other traffic than the transport of the audio data and possible some kind of syncronisation/word_clock. I don't know if this is all-important, but it is an easy step -- turn off arp, dns, dhcp, ... -- since theese can possible interrupt the flow. If you tell us what the "Ethernet Soundcard" should do re. ipv6, I'm more than willing to listen. 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 Tuesday 24 November 2009, Adrian Knoth wrote: And that says it all right there, 4x the channels one can get out of an ADAT. Story time folks: One of my long time employees at the tv station has always had this dream of doing the killer video that would make him a million dollars, so he is always nearly starving to scrap up enough money for the latest whizbang toys. When ADAT's recorders were brand new, he bought 2 of them, they were going to be the heart of the audio portion of his studio. That cost him the majority of a small inheritance, not too far short of 5 figures, and they used vhs tapes at the time. I saw them a couple of times when he had them at the transmitter which was his 'day' job. But I never heard them cuz they didn't talk nice to the rest of the planet, something like a 'vegetarian' being old tribal slang for someone who does hunt or fish well. That nearly 10 grand in gear has since disappeared into his personal museum I guess, never to be heard from (literally) again. The point of the story is both that there is a sucker born every minute, and that the ADAT interface, with its certain legal challenges that have been intimated here many times over the last years, approaching a decade IIRC for me, is a proprietary interface has no place in the free, open for anyone to play with it, scene. ADAT has made their bed, now let them sleep in it. What is being proposed here, with the ethernet interface, is both far easier to do with generic $25/card hardware at the interface point, and far superior in terms of bandwidth. So please do carry on with the ethernet discussion. It is very interesting to listen to the what if's, when its easy enough to do. Couple that with the hardware ADC/DAC being just another exercise for the gEDA folks, who could have you working, completely open hardware in just a couple of months. The only problems I can see, as a broadcast engineer with 45 years experience, would be layout problems on the PCB's that would have to be iterated several times to get the SNR's the ADC's can be capable of, optimized into the real world. As for costs, I haven't googled around to see what 24 bit (or more) monotonic ADC's are worth in 100 lots today, Ditto for DAC's although I suspect 24 bit monotonic comes cheaper in a DAC than in an ADC. The Audigy2, sbo400 based card in this machine certainly wasn't a break the bank purchase even when new, and it claims to be 24 bit. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) The NRA is offering FREE Associate memberships to anyone who wants them. <https://www.nrahq.org/nrabonus/accept-membership.asp> You can't learn too soon that the most useful thing about a principle is that it can always be sacrificed to expediency. -- W. Somerset Maugham, "The Circle"