On 12/01/2009 12:46 AM, Karl Hammar wrote: How many chipsets come with support for adat or firewire ootb? I have used arm, freescale and zilog in the past. None of them did. It will be a challenge to find a reasonably priced chipset that has support for all the above but maybe there is a family out there that can be easily switched without needing major surgery to the board design. The other thing to consider is whether the firmware will be open. I have no problem with an NDA for development purposes but others might not like that. What chipsets have been put forward/decided on so far? I'll get back to you on this. I would like to add usb-2.0/3.0 to the specs. 2.0 is probably easier but 3.0 is more cutting edge. Of course. I have an oscilliscope and some other random hardware for testing with. Once we have an idea of how many people are prepared to contribute to the test phase we can get an idea of what kind of costs we are looking at and whether it is better to purchase in bulk or seperately. I have a server to use for this or we can go with one of the many existing free services. I can contribute funds but cannot afford to fund the project completely. Patrick Shirkey Boost Hardware Ltd

Just to recap. These are the points that have been discussed so far. +++++++++++++++++++++++++++ ------------------- Physical Size ------------------- http://www.rittal.com/products/ArtikelDatenblatt.asp?ArtNr=1360500&lang… 600 mm x 600 mm x 350 mm --------------- Hardware --------------- No decision has been made on the viability of designing a board from scratch. - You have access to this board for development/testing: http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4102 The aim is to provide upto 8 audio i/o ports. Connectivity via Gigabit ethernet. -------------------------- Firmware/Software -------------------------- The device will run Linux OS. Audio data transfer will be via netjack using CELT compression. ------------- Website ------------- Need to define project vision, setup wiki, git-hub etc... +++++++++++++++++++++++++++ - I have a couple of pico-itx boards which are similar to the Atmel boards but a little more powerful http://www.via.com.tw/en/initiatives/spearhead/pico-itx/ Both platforms run Linux natively so that will allow us to get something running fairly quickly for testing purposes. If the above details are correct it looks like the next step is to define the best way to connect external audio i/o to the device. -- Patrick Shirkey Boost Hardware Ltd

On Tue, 1 Dec 2009 19:31:24 +0100 (CET) karl(a)aspodata.se (Karl Hammar) wrote: At this stage, I'd just say whatever is easiest to work with. Shrinkage and prettifying can come later! PCI is on the way out and PCI-x seems to be rather fluid spi seems more future-proof (in as much as anything can be) Very much agree, start simple and see how far we can push it. Initially line only, much easier to get a decent performance. Also there are *lots* of mic preamps out there and everyone thinks theirs is the best :) KISS Status LEDs would be good, but levels should be software controlled, so no need for mechanical switches, Pots, Faders etc. Almost everyone has fast Ethernet, so lets stick with that for as long as possible. It's easier to upgrade than downgrade! I'll just go with the flow here :) Pretty much ticks all the boxes for me. -- 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 12/01/2009 07:31 PM, Karl Hammar wrote: if you are targetting the studio market (or anything other than basic consumer stuff, for that matter), this channel is inadequate. i think 24bits at 48k is a sensible minimum. haven't looked at your intended cpu, but if it can do floats in hardware, 32bit float would be an even better choice. again, consider floats. the very nice advantage is that they can't overload, i.e. you only have to watch the very last meter in your signal chain, not every single stage. does that mean it *can* use CELT (which is cool), or that it always uses CELT (which would be a severe limitation imho)? i've heard arduino is quite popular, so if you that route, it might open up a wider user/contributor base. best, jörn

On Wednesday 02 December 2009 01:39:37 Jörn Nettingsmeier wrote: The arduino microcontroller as such is a bit too slow for audio. There are newer Atmel chips though that could be worth looking at. I'd also look at what CNMAT did with their 120 speakerball, since that uses Gigabit Ethernet to transport audio to it, which then gets converted to signals for the 120 amps that are in there. Probably a good reference for what hardware to look at. sincerely, Marije

On Wed, Dec 02, 2009 at 10:05:51AM -0500, drew Roberts wrote: That's called raw PCM. ;) It's not a good idea. It imposes latencies and there's actually no need for compressed data as long as there is plenty of bandwidth (and there will be, since we're talking LAN) Perhaps having multiple samplewidths is also unnecessarily complicated. As Joerg has pointed out, simply using single precision floats would fit them all. Conversion could still be done on the host CPU, if need be. (but there won't be a need for that if using jackified apps) Just my $0.02 -- mail: adi(a)thur.de http://adi.thur.de PGP/GPG: key via keyserver NTSC: Never the same colour

On Wed, Dec 02, 2009 at 05:41:12PM +0100, torbenh wrote: Don't underestimate today's processors... An XMOS XS1-G4 will do the complete AVB protocol in software, see <http://www.xmos.com/applications/audio/ethernet-avb-audio> -- FA Wie der Mond heute Nacht aussieht ! Ist es nicht ein seltsames Bild ?

On Wed, Dec 02, 2009 at 10:05:51AM -0500, drew Roberts wrote: nothing less. And as most audio ADCs today are 24-bit, I see no point in providing 8 or 16. Even 44.1 kHz for me is something of the past, the only place where it should be used is when mastering a CD. I've noted some other strange things. Why should a soundcard be running Linux, or any other OS for that matter ? Ciao, -- FA Wie der Mond heute Nacht aussieht ! Ist es nicht ein seltsames Bild ?

fons: ... . lower price . as an exercise, learning . use in another projects So, 24bit, 48/96kHz is the spec. to aim at? It doesn't need to, but it might be easier to use an os when developing. When things are running smoothly, you are more than welcome to optimize avay the os. 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 Mon, Dec 07, 2009 at 11:06:23PM +0100, Jens M Andreasen wrote: But take into account that 192 kHz is the same type of marketing scam as gold-plated optical connectors. In other words completely useless. Ciao, -- FA

On Mon, Dec 07, 2009 at 11:02:58PM +0000, Dan Mills wrote: Only if your 192 kHz ADC really is flat above the audio range, and the analog parts of the board are engineered for measurement use. Then it could occasionally be useful. A general purpose measurement system would need a much higher bandwidth. -- FA

On Mon, Dec 7, 2009 at 5:34 PM, &lt;fons(a)kokkinizita.net&gt; wrote i think you underestimate its brilliance. gold-plated connectors are a scam that collects once, and only once, per scam. 192kHz keeps on paying out for disk manufacturers, RAM suppliers and CPU makers for months, even years after the initial scam has been pulled off. not only that, but you can even sub-scam your friends by pointing out how much better it all sounds, and they'll be even more afraid to note that it doesn't because, well, everybody understands gold, whereas ... kHZ ??

On Tue, Dec 08, 2009 at 12:47:32AM +0100, Jörn Nettingsmeier wrote: No such problem a few meters deep in the water. If you want to cover all sorts of sonar applications as well, pump up the sample rate to 1 MHz or so... Ciao, -- FA

On Tue, Dec 01, 2009 at 06:22:20PM +1100, Patrick Shirkey wrote: heh ? you dont want lossy compression for a soundcard. if you only intend to transmit 8 channels you dont need that. -- torben Hohn

On Tue, Dec 01, 2009 at 09:20:07AM +1100, Patrick Shirkey wrote: Hi! I'm not sure if I understand the question correctly, but that's the only chip I know, and luckily, it supports ADAT and Firewire. ;) http://www.tctechnologies.tc/index.php?option=com_content&view=article&… HTH -- mail: adi(a)thur.de http://adi.thur.de PGP/GPG: key via keyserver

Karl Hammar wrote: If you really want to go the ethernet route you could look at the DM870: http://www.bridgeco.com/index.php?option=com_content&task=view&id=4… This has onboard ethernet and USB (at 480Mbit), and runs linux. Greets, Pieter PS: personally I think that going for the TCAT DICE would be a smarter move as this chip has been designed for pro-audio and lot's of channels. It should not be too difficult to interface it to something that has gigabit-ethernet if you really want to. But there are plenty of technical reasons to choose firewire over ethernet (or USB).

Karl Hammar wrote: The most important argument would be that firewire provides the bandwidth, QOS and latency guarantees that ethernet (currently) lacks. Furthermore it also gives access to a global clock which is essential to maintain proper synchronization in a networked environment. Most of these fundamental issues are being addressed by the relevant IEEE 802 spec groups, but those are still in the specification phase, so the hardware you get now will not support this. Note that some hardware available now might be good enough to cut it. But you're going to get 'customers' that expect such a device to work with the onboard laptop ethernet controller (which is first optimized for cost, then optimized for throughput, then maybe for latency). And suppose your laptop happens to have one that doesn't cut it, I wonder how easy it is to find a good ethernet cardbus/expresscard given the fact that all laptops have ethernet on-board for ages now (hence there is virtually no market for add-on ethernet cards). My experience with firewire learns me that even if the specs cover the fundamental issues (as is the case in firewire), the actual chipsets implementing them can (and do) add a load of side-issues to the equation. You need a solid foundation to build on, as chipset vendors cut all corners they can to reduce costs. And *current* ethernet isn't a good foundation for audio. You might want to ask yourself whether you want to go through the hassle of designing an open source soundcard which is only usable in a very controlled environment, i.e. if people have ethernet card X from vendor Y and use switches that use a chipset from vendor Z, being the devices from [insert customers from Z here]. It's a support nightmare. Note that the host-side challenges of using ethernet should not be underestimated. You will have to modify the kernel ethernet driver(s) to discriminate between audio and other packets in a very early stage. Otherwise your audio packets will be deferred to a tasklet and will hence be competing with e.g. video and disk workloads. This issue is currently also present in the 1394 drivers, but the main differences are that there is only one hardware driver for 1394 (as all cards adhere to the OHCI specification) and hence only one place to solve this issue. I don't even want to start counting the number of ethernet drivers in the Linux kernel. A second important difference is that the ethernet subsystem in Linux is used/maintained by people that couldn't care less about audio on Linux, let alone ethernet+audio on Linux. So I think that your chances of getting patches into the kernel that implement things like shifting work from a tasklet to the interrupt handler just for audio might encounter some resistance. </me now really puts his FFADO hat on> Furthermore I think it would be a more directed effort to use a platform like BeBoB or DICE and leverage the work that has already been done, both on the hardware side as on the Linux side (i.e. FFADO). These platforms basically offer everything except for the data-converters and analog stages. Hence the only challenge is designing the (analog) hardware itself. Which IMHO should be a significant one on its own. The added benefit of using an established platform is that it will also work on OSX and windows, meaning that you can reach a larger audience with the hardware and hence have more traction for such a project. Re-writing every kernel ethernet driver to take audio requirements into account and trying to push this into mainline is a waste of time. Maintaining a separate patch-set is a waste of time. Waiting for the specs to settle is a waste of time. A better use of this time would be to improve the FFADO infrastructure (e.g. by implementing a kernel-space streaming driver). This would also benefit the users of the commercial firewire products and would hence help the community as a whole. In the mean time you have a workable solution on the host-side. No offense intended, but the Linux Audio community isn't helped with (yet another) half-baked solution. Note that I don't consider FFADO as fully-baked either. But at least it is already half-baked *at this moment in time*. The challenge is not in starting another project, but in bringing it to a usable level. Unfortunately for open-source the most fun is found in the beginning of a project, where you see a lot of progress. Bringing the project to the usable level however isn't much fun. It means spending several days to find that one rarely occurring bug that makes the system unreliable for long recording sessions or live use. The people that actually enjoy the latter are very rare. So to summarize my opinion: * Low-latency (semi-)pro-audio over ethernet as a concept is not mature and is not a good foundation to build something on that is not a support nightmare. * The ethernet hardware that is abundantly available is probably not usable for audio, even if the 'concept' was mature. * The mainline Linux kernel will not be ready for ethernet audio for a while to come, maybe even due to non-technical reasons. * It is a better use of time to build on and improve what is already there than to re-invent the wheel. Obviously not all things I mention are technical, but as I was typing anyway... Greets, Pieter PS: I didn't want to go into the USB vs FireWire debate, there's plenty of material on that. But I think that even USB is a better idea than ethernet, not because its technically superior but because there is a better ecosystem for audio+usb.

On 12/07/2009 05:36 AM, Gene Heskett wrote: Slightly off topic but... I have had the pleasure of working with multiple usb devices (in the 1000's) and I can say that I was able to get a 4 core, intel with 8GB RAM to handle 500 devices at the same time with additonal pci->usb cards. The only ones worth any time are made by Belkin. To stream data to so many devices at one time you need a lot of available memory. 2GB will handle about 100 devices nicely without sacrificing any transfer speed. A single USB 7 port hub can be made to chain 1x7 port hub-> 7 x 7 port hub-> 1 x 4 port hub to give a total of 50 devices at one time. You can modularise this chain to get 100 devices running off 1 usb bus. I have my systems installed at La Louvre for instance where they are running very well. I had no chance to test latency for audio recording but from my experience there are only two usb-2.0 chips on the market that get anywhere near the 480Mb/s bandwidth available for usb-2.0 and they are both used by Belkin. My experience with usb cable lengths > 3 meters is that they require a booster. Patrick Shirkey Boost Hardware Ltd

On Tue, 01 Dec 2009 09:20:07 +1100 Patrick Shirkey &lt;pshirkey(a)boosthardware.com&gt; wrote: I have some concern that too much addition to the spec, will end up with a monstrosity that is a nightmare to build, and no more compatible with the core goal than anything else already available :( My new millivoltmeter/dB meter is nearly finished - All I need now is precision resistors 9M, 900k, 90k :? I'll be able to contribute some funds as well -- 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 Tue, 1 Dec 2009 21:46:32 +0100 (CET) karl(a)aspodata.se (Karl Hammar) wrote: It is simple enough, so as soon as I can find the time I'll draw out the schematic and post it here as a PDF attachment. -- 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 Thu, Dec 03, 2009 at 10:29:54PM +0000, Folderol wrote: Mmmm. Just 1 picofarad of stray capacitance on the switch and wiring, in parallel with 9M, will create a filter with its 3 dB frequency in the audio band. And 1 pf is really nothing, expect more. This will lead to gross errors at anything but the lowest frequencies. Is there any reason why an audio level meter should have such a high input impedance ? Ciao, -- FA Wie der Mond heute Nacht aussieht ! Ist es nicht ein seltsames Bild ?

On Thu, Dec 03, 2009 at 11:13:05PM +0000, Folderol wrote: They are not so 'standard' today, and probably difficult to find. Bandwidth will not be the problem. What you get is a filter that will boost HF. 1 pf = +3dB at 17.7 Khz on all but the 20 mV range. 10 pf means +3dB at 1.77 kHz, and rising. Even a 1M input would require at trimmer across the 0.9M resistor and fixed Cs for the others. The only reliable way to have 10M is to use an external calibrated probe feeding into a standard 1M input (which then will need a calibrated capacitance as well). Ciao, -- FA

First an apology. There is an error in the drawing (I knew I should have waited a couple of days before posting it). The bias for the first OpAmp (pin 8) is shown going to +V. It should go to Gnd. As shown it is in the low current - low bandwidtch mode, which is fine for the second one of course. On Fri, 4 Dec 2009 00:51:12 +0100 fons(a)kokkinizita.net wrote: http://uk.rs-online.com/web/search/searchBrowseAction.html?method=getProduc… Cheap modern equivalent, although a bit smaller. http://uk.rs-online.com/web/search/searchBrowseAction.html?method=getProduc… Very expensive 'full size' switch. Unfortunately only available as BBM - I prefer MBB for sensitive input stuff. I decided to do some more detailed investigations, because while I totally accept your statements, the actual measured results were quite different. I was getting an essentially flat response right the way up to 99.9kHz, a little wobble between ranges but no more that +2dB, and about +1dB at 40kHz. Taking the cover off I noticed and immediate jump to about +3dB at 99(etc)kHz and taking the unit out of the box completely while being careful to avoid moving anything resulted in a further increase to +4 to 5dB, also becoming quite variable. Clearly stray capacitance to the box shielding was affecting the response. Because I was unable to get 9M 0.1% resistors I used three lower values in series shaped as a 'C' across the tags, so I wondered if the 'spread' of effective resistor body was having an effect too. As a test I temporarily replaced this with a standard 10M resistor. Response was now +2 to 3dB at 40kHz and about +8dB at the top end. While I don't know the whole story of what capacitances there are to where, even the worst of these variants still gave a just about usable performance, so I simply put everything back as it was :) Incidentally total current consumption is a sniff over 1.3mA. -- 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 Thursday 03 December 2009 18:13:05 Folderol wrote: Check my lyrics (poems?) here: http://packet-in.org/repo/user_drewRoberts/ if you have any tunes that fit we can have us some songs. all the best, drew