[LAD] FOSS Ethernet Soundcard

[Folderol]

Recent discussion on LAU morphed into an idea for an Ethernet driven
sound card, and as this is now becoming a real development the
suggestion was made that it would be better to transfer the discussion
here.


The rationale in brief:

No proprietry hardware soundcard needed.

Almost all modern computers have reasonably fast Ethernet connections.

Potentially up to 20 channels per card - reality will probably be a lot
different!

FOSS drivers to connect Ethernet to whatever audio server is on the
computer - looking at jack right now.

FOSS within the soundcard module so that protocols/algorythings can be
tuned for best results.

FOSH design enabling hardware to be developed and inproved by anyone.

A number of people have shown interest in this, and we are at the stage
of starting to knock together some basic hardware for a feasibility
study.


State of play:

On Mon, 23 Nov 2009 14:39:48 +0100 (CET)
***@aspodata.se (Karl Hammar) wrote:

> Folderol:
> > On Sat, 21 Nov 2009 12:25:36 +0100 (CET)
> > ***@aspodata.se (Karl Hammar) wrote:
> >
> > <snip>
> >
> > > Would this project plan be ok:
> > >
> > > software and hw: Karl
> > > testing and spec's: Folderol
> > > publication via web: anyone??
> > >
> > > git repo: git://aspodata.se/openhw.git
> > > mailing list: hopefully this list, else I put one up at my site
> > > web site: ??
> > >
> > > intial platforms (both by Atmel):
> > > . ATNGW100 (cheap), and
> > > . AT91SAM9260-EK (expensive)
> > >
> > > Next step:
> > > . set up development platform
> > > . simple test with spi and shift registers
> > >
> > > Regards,
> > > /Karl
> >
> > This is all fine by me, but I would make quite clear that if someone
> > comes along with access to a {loadsamoney} spectrum analyser I'd be
> > perfectly happy to step back and take a more supporting role.
>
> Ok, I should get starting then.
>
> Regards,
> /Karl


Others would be welcome to come on board - pardon the pun!

--
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.

[Adrian Knoth]

On Mon, Nov 23, 2009 at 08:28:03PM +0000, Folderol wrote:

> The rationale in brief:
> No proprietry hardware soundcard needed.
> Almost all modern computers have reasonably fast Ethernet connections.

Don't know how much you already did for the hardware layout. If
possible, try to avoid analog stuff, that is, ADC/DAC.

There are plenty of high quality ADAT converters around, the only
problem is the ADAT spec. AFAIK, it doesn't come for free or it isn't
easy to buy ICs which convert ADAT to some raw format. (I had a look at
this approx. five years ago, but never decided to really build it, so
things might have changed).

I'm also somewhat interested in the network part, I feel IPv6 could help
a lot. It supports autoconfiguration and it has decent multicast
support, so it would be possible to broadcast/multicast the streams on
the net (LAN). This could be useful if you want to access the stream at
a mixing console for a life setup and simultaneously record it on a
computer.

That's basically what Roland's Digital Snake offers: an onstage Ethernet
(not IP) soundcard and one or more remote devices. RockNet provides
similar stuff, there's also Ethersound, but RockNet is PC-incompatible
(400MBit/s proprietary protocol), Roland is undocumented and I don't
know nothing about Ethersound. ;)


I also have some fancy Xilinx boards with onboard ethernet, an audio
codec (including the analog jacks) and a FPGA. Though it's way harder to
mimic all the features with VHDL, it could provide stable timings. The
boards also support memory, so it would be possible to load a softcore
and run Linux on them.


If you like, feel free to Cc me or join #lad if you think I could
contribute something.


Cheerio

--
mail: ***@thur.de http://adi.thur.de PGP/GPG: key via keyserver

[Nick Copeland]

> I'm also somewhat interested in the network part, I feel IPv6 could help
> a lot. It supports autoconfiguration and it has decent multicast
> support, so it would be possible to broadcast/multicast the streams on
> the net (LAN). This could be useful if you want to access the stream at
> a mixing console for a life setup and simultaneously record it on a
> computer.

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/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_3:092010

[b***@email.it]

Anybody know something about IEEE 802.1 AVB ?


Il giorno mar, 24/11/2009 alle 00.05 +0100, Nick Copeland ha scritto:
> > I'm also somewhat interested in the network part, I feel IPv6 could
> help
> > a lot. It supports autoconfiguration and it has decent multicast
> > support, so it would be possible to broadcast/multicast the streams
> on
> > the net (LAN). This could be useful if you want to access the stream
> at
> > a mixing console for a life setup and simultaneously record it on a
> > computer.
>
> 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.
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-***@lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

[Karl Hammar]

Nick Copeland:
> Adrian Knoth:
> > I'm also somewhat interested in the network part, I feel IPv6 could help
> > a lot. It supports autoconfiguration and it has decent multicast
> > support, so it would be possible to broadcast/multicast the streams on
> > the net (LAN). This could be useful if you want to access the stream at
> > a mixing console for a life setup and simultaneously record it on a
> > computer.
>
> 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.

Ack, a standard ip-stream is a sensible first choise.

> Perhaps the project needs to be specified with regards to its goals?
...

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 ***@aspodata.se
Lilla Aspö 148 Networks
S-742 94 Östhammar [phone] Computers
Sweden [phone] Consulting
-----------------------------------------------------------------------

[Patrick Shirkey]

On 11/29/2009 03:36 PM, Ken Restivo wrote:
> On Tue, Nov 24, 2009 at 10:33:45AM +0100, Karl Hammar wrote:
>
>> Nick Copeland:
>>
>>> Adrian Knoth:
>>>
>>>> I'm also somewhat interested in the network part, I feel IPv6 could help
>>>> a lot. It supports autoconfiguration and it has decent multicast
>>>> support, so it would be possible to broadcast/multicast the streams on
>>>> the net (LAN). This could be useful if you want to access the stream at
>>>> a mixing console for a life setup and simultaneously record it on a
>>>> computer.
>>>>
>>> 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.
>>>
>> Ack, a standard ip-stream is a sensible first choise.
>>
>>
>>> Perhaps the project needs to be specified with regards to its goals?
>>>
>> ...
>>
>> My goals is "just" to extend another project (industrial i/o).
>> What would your goals be ?
>>
>> Shall we decide on a single mailing list ?
>>
>>
> IIRC the motivation for this was:
>
> 1) Firewire is going away on laptops
> 2) USB 2.0 is proprietary and non-standard
> 3) Because of (1) and (2), Linux Audio users will soon be left without any way to do multichannel recording on laptops.
>
> The original thread converged on a goal pretty quickly: an inexpensive, multi-channel audio interface which is open hardware and software, and uses Gig Ethernet as its physical connection method.
>
> So, if I were going to put the goal simply: I'd like a Focusrite Saffire (or equivalent) that runs over Ethernet, please :-) Price-wise, it'd be nice if it cost the same or less than equivalent USB 2.0 product. Latency-wise, comparable with USB 2.0.
>
> In terms of how many I/O, I think that was still being calculated and experimentation was going to be required. Obviously options for 4, 8, or 16 I/O would be nice.
>
>


Did anyone have a good reason for not including support for a
usb-1.0/2.0/3.0 interface seeing as we can write the driver ourselves
and adhere to the standard?

Most chipsets these days have support for both port types. It would be
very useful if the schematic provided tracks for both ootb.

BTW, I will be able to contribute development funds towards this project
if required once we have a BoM.



Cheers.


Patrick Shirkey
Boost Hardware Ltd

[Karl Hammar]

***@boosthardware.com:
> On 11/29/2009 03:36 PM, Ken Restivo wrote:
> > On Tue, Nov 24, 2009 at 10:33:45AM +0100, Karl Hammar wrote:
...
> >> My goals is "just" to extend another project (industrial i/o).
> >> What would your goals be ?
...
> > The original thread converged on a goal pretty quickly: an
> > inexpensive, multi-channel audio interface which is open hardware and
> > software, and uses Gig Ethernet as its physical connection method.
...
> Did anyone have a good reason for not including support for a
> usb-1.0/2.0/3.0 interface seeing as we can write the driver ourselves
> and adhere to the standard?

The usual open source reasons, time and interest, and maybe money.

If someone provides the usb-knowledge (or firewire, adat, ... etc.)
I'd be happy to have it included, and I assume others would not mind.
Or, others might include it. I encourage people do their own versions.

> Most chipsets these days have support for both port types. It would be
> very useful if the schematic provided tracks for both ootb.

It should be doable, please tell us what components to inlucde.

> BTW, I will be able to contribute development funds towards this project
> if required once we have a BoM.

I think the most valueable contributions would be

. a good set of specs to aim at (I cannot provide that)
. hw and sw knowledge
. testing and evaluation, and equipment for that
. prototype boards for testers
. components, chips and mundane things like that
. cummunication, git-repo, webserver, mailing list, ...

If someone wish to contract me to work on this, I'd be happy, but
that is not a requirement.

Regards,
/Karl

-----------------------------------------------------------------------
Karl Hammar Aspö Data ***@aspodata.se
Lilla Aspö 148 Networks
S-742 94 Östhammar [phone] Computers
Sweden [phone] Consulting
-----------------------------------------------------------------------

[Patrick Shirkey]

On 12/01/2009 12:46 AM, Karl Hammar wrote:
> ***@boosthardware.com:
>
>> On 11/29/2009 03:36 PM, Ken Restivo wrote:
>>
>>> On Tue, Nov 24, 2009 at 10:33:45AM +0100, Karl Hammar wrote:
>>>
> ...
>
>>>> My goals is "just" to extend another project (industrial i/o).
>>>> What would your goals be ?
>>>>
> ...
>
>>> The original thread converged on a goal pretty quickly: an
>>> inexpensive, multi-channel audio interface which is open hardware and
>>> software, and uses Gig Ethernet as its physical connection method.
>>>
> ...
>
>> Did anyone have a good reason for not including support for a
>> usb-1.0/2.0/3.0 interface seeing as we can write the driver ourselves
>> and adhere to the standard?
>>
> The usual open source reasons, time and interest, and maybe money.
>
> If someone provides the usb-knowledge (or firewire, adat, ... etc.)
> I'd be happy to have it included, and I assume others would not mind.
> Or, others might include it. I encourage people do their own versions.
>
>


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?


>> Most chipsets these days have support for both port types. It would be
>> very useful if the schematic provided tracks for both ootb.
>>
> It should be doable, please tell us what components to inlucde.
>


I'll get back to you on this.


>
>> BTW, I will be able to contribute development funds towards this project
>> if required once we have a BoM.
>>
> I think the most valueable contributions would be
>
> . a good set of specs to aim at (I cannot provide that)
>


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.




> . hw and sw knowledge
>

Of course.


> . testing and evaluation, and equipment for that
>


I have an oscilliscope and some other random hardware for testing with.


> . prototype boards for testers
> . components, chips and mundane things like that
>

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.

> . cummunication, git-repo, webserver, mailing list, ...
>

I have a server to use for this or we can go with one of the many
existing free services.


> If someone wish to contract me to work on this, I'd be happy, but
> that is not a requirement.
>
>

I can contribute funds but cannot afford to fund the project completely.



Patrick Shirkey
Boost Hardware Ltd





> Regards,
> /Karl
>
> -----------------------------------------------------------------------
> Karl Hammar Aspö Data ***@aspodata.se
> Lilla Aspö 148 Networks
> S-742 94 Östhammar [phone] Computers
> Sweden [phone] Consulting
> -----------------------------------------------------------------------
>
>
>
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-***@lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
>

[Karl Hammar]

Patrick Shirkey:
> On 12/01/2009 12:46 AM, Karl Hammar wrote:
...
> > If someone provides the usb-knowledge (or firewire, adat, ... etc.)
> > I'd be happy to have it included, and I assume others would not mind.
> > Or, others might include it. I encourage people do their own versions.
> How many chipsets come with support for adat or firewire ootb? I have

Not the faintest idéa.

> 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.

I avoid it if I can.

> What chipsets have been put forward/decided on so far?

Not much decided for yet. I have e.g. got response [1] and [2].
In summary:

. AT32NGW100 [3] seems to be an affordable cpu-card we can start with
. 4/8/16 channels of 24bit/48kHz perhaps 96kHz

My preliminary roadmap is in [4].

++

On the mechanical side, the system I will design has to fit into
industrial enclosures like [5].

I'm looking into using a 6U, probably half to quarter width 19"
card frame system. With card size 160x233mm, or I might shrink
that to 100x233mm to make them more easily fit into an enclosure.
I will need the 233mm height for all the i/o connectors. It
feels like connectors will take more space than the electronics,
well, maybe not. But connectors will need more space than what
a single 3U eurocard can provide.

The reason for a card frame system is that the user should be
able to easily pull out or insert a card for repair or upgrade.

This implies a backplane, and I will probably use something
VME-like so one CAN buy a readymade backplane if one wish to.

A card frame system gives you an instant extra cost which
might no be that useful for an audio application. But hopefully
one can reuse blocks of schematics and pcb designs if someone else
would like a single card or a stacked system solution.
I'm currently looking into the cost for the card frame, and I might
do my own drawing and ask the local smithery for the sheet metal
work to decrease cost and to make it fit into the enclosure.

Unless someone convinces me on something else,
I will in the end use the AT91SAM9260 for my project. I don't
see that that should hinder anyone else to use something
else if we can do a suitable cut between the "cpu-part" and the
"i/o-part". Well, in a backplane based system you already have that.
This processor runs at ~200MHz, so you cannot do that much
prosessing on it, but it can run linux. I want an Compact-Flash
socket on the cpu-card for easy software deployment.

...
> >> BTW, I will be able to contribute development funds towards this project
> >> if required once we have a BoM.
> > I think the most valueable contributions would be
> > . a good set of specs to aim at (I cannot provide that)
>
> 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.

If you know the tradeoffs, please decide. "My" processor has usb-2.0
onchip (both "host" and "device" port), but only at 12Mbps. To use
something faster we need to have a separate usb chip.
I don't think the sam9260 will be sufficient for driving the usb at
480Mbps, but I might be wrong.

...
> > . testing and evaluation, and equipment for that
> I have an oscilliscope and some other random hardware for testing with.

Same here, and Folderol [2] also had some equipment.

> > . prototype boards for testers
> > . components, chips and mundane things like that
> 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

So far, it seems that it is you, me and Folderol.

> at and whether it is better to purchase in bulk or seperately.

Since your company is based in Tailand, and mine in Sweden, I think we
have to split it, at least per continent for common electronic
components, unless we are beginning to sell in volumes.

Pcbs could be a good thing to share. I'm going to get silkscreen
equipment, so when we go beyound breadboard and possible wire/wrap,
I could provide thoose (without plated via's tough).

> > . cummunication, git-repo, webserver, mailing list, ...
> I have a server to use for this or we can go with one of the many
> existing free services.

Me too. But I will not maintain webpages. That is open for someone else.

> > If someone wish to contract me to work on this, I'd be happy, but
> > that is not a requirement.
> I can contribute funds but cannot afford to fund the project completely.

We have to have something going before one knows if any funds are
worthwile.

Regards,
/Karl

[1] http://lists.linuxaudio.org/pipermail/linux-audio-user/2009-November/064959.html
[2] http://lists.linuxaudio.org/pipermail/linux-audio-user/2009-November/064988.html
[3] http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4102
[4] http://lists.linuxaudio.org/pipermail/linux-audio-user/2009-November/064962.html
[5] http://www.rittal.com/products/ArtikelDatenblatt.asp?ArtNr=1360500&lang=GB

-----------------------------------------------------------------------
Karl Hammar Aspö Data ***@aspodata.se
Lilla Aspö 148 Networks
S-742 94 Östhammar [phone] Computers
Sweden [phone] Consulting
-----------------------------------------------------------------------

[Patrick Shirkey]

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=GB

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

[Karl Hammar]

Patrick Shirkey:
> 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=GB
>
> 600 mm x 600 mm x 350 mm

No, this is where I will put my system into. The actual "computer"
would be much smaller. I'm planning on something like

h: ~240, w: <200, d: < 200mm

But I don't think you should have to abide to that.

+++++

For the "soundcard" part, it might be more useful if we instead talk
about interfaces.

With SPI, we are free to "attach" many different cpu-cards, it's just
clock, data out, data in, and a few chip select lines. And we can
potentially get 10-20 channels at cd quality.

With faster i/o, we can use the cpu's memory interface, or
some ordinary bus like pci or pci-x.

I'm not for pci or pci-x at this point, since that would be for me a
totally different project. Unless, of cause, someone else takes care
about the "bus" part, and I and others do the ad/da and analog part.

With spi or the memory bus, we cannot use an ordinary pc --- to bad.
But we could use the atmel network card mentioned a few lines below,
or the card I will eventually build, or some card someone else provides
source to.

> ---------------
> Hardware
> ---------------
> No decision has been made on the viability of designing a board from
> scratch.

I will probably do everything from scratch, but given good and
sensible interfaces card<->card, one could possible use "any"
suitable cpucard.

> - You have access to this board for development/testing:
> http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4102

Ack.

> The aim is to provide upto 8 audio i/o ports.

I don't think we should set an upper limit, instead it would be
interesting to see how many channels the system could support.

I would say we try to make (input and output)

one desent channel, e.g. 16bits, 44.1/48kHz
one very good channel (if we manage), 24bits 192kHz, to try the limits

And then see how many we can fit into the system.

And, would that be an line input, or mic input channel, or
(software) switchable?

Talking about, i/o. Would buttons, leds, relays, linear and rotary
things (what is their name?), etc. be useful ?

> Connectivity via Gigabit ethernet.

I don't think the atmel can do gigabit. Fast ethernet (100Mpbs),
is a more realistic choise unless we switch cpu.

> --------------------------
> Firmware/Software
> --------------------------
> The device will run Linux OS.
> Audio data transfer will be via netjack using CELT compression.

Ack.

> -------------
> Website
> -------------
> Need to define project vision, setup wiki, git-hub etc...

Ack.

I have some readme's at [2], and I will put all my other design files
there.

Here are some thoughts (extract from [3]):

The requirements are
. it should run linux
. developed with open source tools, current choise is gEDA
. expandable, you be able to easily add e.g. 8 D/A ports, 32 DIO etc.
preferably hotpluggable
. electrically rugged and EMC safe
. easy to make and build yoursalf, preferable double layer card
. the components should be available/purchable for a normal hardware hacker
. the should not cost to "much"
. no card edge connector

It seems that my "archetectural" choises are
. a single board computer
. a stackable system like pc104, pico-itxe or arduino
. a card frame system, either
- whith a backplane bus, like VME or CompactPCI
- or with the "backplane" on the cpu card, the motherboard style like ATX

The one which is easiest to expand is the card frame system with a backpland,
I will make my first try with that.

> - 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/

They don't have a spi master on board we could use for slow i/o,
nor can we easily attach things to the memory bus for fast i/o.
So for the industrial control thing theese are not that easy to use.
(I have checked all the itx cards, and all except one states that the
spi is for testing (I assume jtag) purposes only).

If we go the mini/micro/nano/pico-itx route, I think we need to make an
pci/pci-x card. That would be nice, but I don't think I'm up to that
yet, are you?

There is also a pico-itx -e version that has a so-called sumit [1]
connector.

> Both platforms run Linux natively so that will allow us to get something
> running fairly quickly for testing purposes.

I don't see any pricipal difference between X-itx card and an ordinary
pc. If we say we want it to run on a X-itx card, that would be the same
as saying it should run on an ordinary pc. And that would imply
pci-x I guess.

> 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.

Regards,
/Karl

[1] www.via.com.tw/en/downloads/datasheets/initiatives/FAQ081029Pico-ITXe-P710.pdf
[2] git://aspodata.se/openhw.git
[3] http://aspodata.se/openhw/README
-----------------------------------------------------------------------
Karl Hammar Aspö Data ***@aspodata.se
Lilla Aspö 148 Networks
S-742 94 Östhammar [phone] Computers
Sweden [phone] Consulting
-----------------------------------------------------------------------

[Folderol]

On Tue, 1 Dec 2009 19:31:24 +0100 (CET)
***@aspodata.se (Karl Hammar) wrote:

> Patrick Shirkey:
> > 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=GB
> >
> > 600 mm x 600 mm x 350 mm
>
> No, this is where I will put my system into. The actual "computer"
> would be much smaller. I'm planning on something like
>
> h: ~240, w: <200, d: < 200mm
>
> But I don't think you should have to abide to that.
>
> +++++

At this stage, I'd just say whatever is easiest to work with. Shrinkage
and prettifying can come later!

> For the "soundcard" part, it might be more useful if we instead talk
> about interfaces.
>
> With SPI, we are free to "attach" many different cpu-cards, it's just
> clock, data out, data in, and a few chip select lines. And we can
> potentially get 10-20 channels at cd quality.
>
> With faster i/o, we can use the cpu's memory interface, or
> some ordinary bus like pci or pci-x.
>
> I'm not for pci or pci-x at this point, since that would be for me a
> totally different project. Unless, of cause, someone else takes care
> about the "bus" part, and I and others do the ad/da and analog part.
>
> With spi or the memory bus, we cannot use an ordinary pc --- to bad.
> But we could use the atmel network card mentioned a few lines below,
> or the card I will eventually build, or some card someone else provides
> source to.

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)

> > ---------------
> > Hardware
> > ---------------
> > No decision has been made on the viability of designing a board from
> > scratch.
>
> I will probably do everything from scratch, but given good and
> sensible interfaces card<->card, one could possible use "any"
> suitable cpucard.
>
> > - You have access to this board for development/testing:
> > http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4102
>
> Ack.
>
> > The aim is to provide upto 8 audio i/o ports.
>
> I don't think we should set an upper limit, instead it would be
> interesting to see how many channels the system could support.

Very much agree, start simple and see how far we can push it.

> I would say we try to make (input and output)
>
> one desent channel, e.g. 16bits, 44.1/48kHz
> one very good channel (if we manage), 24bits 192kHz, to try the limits
>
> And then see how many we can fit into the system.
>
> And, would that be an line input, or mic input channel, or
> (software) switchable?

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 :)

> Talking about, i/o. Would buttons, leds, relays, linear and rotary
> things (what is their name?), etc. be useful ?

KISS
Status LEDs would be good, but levels should be software controlled, so
no need for mechanical switches, Pots, Faders etc.

> > Connectivity via Gigabit ethernet.
>
> I don't think the atmel can do gigabit. Fast ethernet (100Mpbs),
> is a more realistic choise unless we switch cpu.

Almost everyone has fast Ethernet, so lets stick with that for as long
as possible. It's easier to upgrade than downgrade!

> > --------------------------
> > Firmware/Software
> > --------------------------
> > The device will run Linux OS.
> > Audio data transfer will be via netjack using CELT compression.
>
> Ack.

I'll just go with the flow here :)

> > -------------
> > Website
> > -------------
> > Need to define project vision, setup wiki, git-hub etc...
>
> Ack.
>
> I have some readme's at [2], and I will put all my other design files
> there.
>
> Here are some thoughts (extract from [3]):
>
> The requirements are
> . it should run linux
> . developed with open source tools, current choise is gEDA
> . expandable, you be able to easily add e.g. 8 D/A ports, 32 DIO etc.
> preferably hotpluggable
> . electrically rugged and EMC safe
> . easy to make and build yoursalf, preferable double layer card
> . the components should be available/purchable for a normal hardware hacker
> . the should not cost to "much"
> . no card edge connector
>
> It seems that my "archetectural" choises are
> . a single board computer
> . a stackable system like pc104, pico-itxe or arduino
> . a card frame system, either
> - whith a backplane bus, like VME or CompactPCI
> - or with the "backplane" on the cpu card, the motherboard style like ATX
>
> The one which is easiest to expand is the card frame system with a backpland,
> I will make my first try with that.

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.

[Karl Hammar]

Folderol:
> On Tue, 1 Dec 2009 19:31:24 +0100 (CET)
> ***@aspodata.se (Karl Hammar) wrote:
> > [about sizes]
> At this stage, I'd just say whatever is easiest to work with. Shrinkage
> and prettifying can come later!

Ok, forget about physical size for now.

...
> > > The aim is to provide upto 8 audio i/o ports.
> > I don't think we should set an upper limit, instead it would be
> > interesting to see how many channels the system could support.
> Very much agree, start simple and see how far we can push it.

Ok.

...
> 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 :)

Ok.

...
> > > Connectivity via Gigabit ethernet.
> > I don't think the atmel can do gigabit. Fast ethernet (100Mpbs),
> > is a more realistic choise unless we switch cpu.
> Almost everyone has fast Ethernet, so lets stick with that for as long
> as possible. It's easier to upgrade than downgrade!
...

Ok.

******

I then propose that this project (for the moment) consentrates on the
analog and ad/da part.

I.e.:

. design a 16bit 44.1/48kHz, line-in block
. design a 16bit 44.1/48kHz, line-out block
. design a 24bit 192kHz, line-in block
. design a 24bit 192kHz, line-out block

All with spi, without any consideration about multichannel, usb/
ethernet/whatever -- do the analog part good, then we can use it
together with "any" cpucard.

******

Would that be something which could move this project forward ?

In meantime while we are working on this, the thoughts about processor,
usb/adat/firewire/ethernet etc. may have its time to mature.

Those of you more interested about other parts of a future system can
work out thoose details so that they are clear when the analog/ad/da
blocks matures.

Regards,
/Karl

-----------------------------------------------------------------------
Karl Hammar Aspö Data ***@aspodata.se
Lilla Aspö 148 Networks
S-742 94 Östhammar [phone] Computers
Sweden [phone] Consulting
-----------------------------------------------------------------------

[Jörn Nettingsmeier]

On 12/01/2009 07:31 PM, Karl Hammar wrote:

>> The aim is to provide upto 8 audio i/o ports.
>
> I don't think we should set an upper limit, instead it would be
> interesting to see how many channels the system could support.
>
> I would say we try to make (input and output)
>
> one desent channel, e.g. 16bits, 44.1/48kHz

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.

> one very good channel (if we manage), 24bits 192kHz, to try the limits

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.

>> The device will run Linux OS.
>> Audio data transfer will be via netjack using CELT compression.
>
> Ack.

does that mean it *can* use CELT (which is cool), or that it always uses
CELT (which would be a severe limitation imho)?

> It seems that my "archetectural" choises are
> . a single board computer
> . a stackable system like pc104, pico-itxe or arduino

i've heard arduino is quite popular, so if you that route, it might open
up a wider user/contributor base.


best,

jörn

[Michael Chapman]

1)
On Wednesday 02 December 2009 6:39 am, Jörn Nettingsmeier
<***@folkwang-hochschule.de> wrote:

>
> 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.
>

At the risk of repeating myself: Yes, floats would be the ideal way to go.

2)
If I can assist on Web matters, that offer remains open.

MC

[nescivi]

On Wednesday 02 December 2009 01:39:37 Jörn Nettingsmeier wrote:
> > It seems that my "archetectural" choises are
> > . a single board computer
> > . a stackable system like pc104, pico-itxe or arduino
>
> i've heard arduino is quite popular, so if you that route, it might open
> up a wider user/contributor base.

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

[drew Roberts]

On Tuesday 01 December 2009 13:31:24 Karl Hammar wrote:
> > --------------------------
> > Firmware/Software
> > --------------------------
> > The device will run Linux OS.
> > Audio data transfer will be via netjack using CELT compression.
>
> Ack.

Can CELT also do uncompressed or lossless? Otherwise limiting to CELT might
not be such a good idea if I have followed things closely enough.

all the best,

drew

[Adrian Knoth]

On Wed, Dec 02, 2009 at 10:05:51AM -0500, drew Roberts wrote:

> > > Audio data transfer will be via netjack using CELT compression.
> > Ack.
> Can CELT also do uncompressed or lossless?

That's called raw PCM. ;)

> Otherwise limiting to CELT might not be such a good idea if I have
> followed things closely enough.

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: ***@thur.de http://adi.thur.de PGP/GPG: key via keyserver

NTSC: Never the same colour

[torbenh]

On Wed, Dec 02, 2009 at 04:20:45PM +0100, Adrian Knoth wrote:
> On Wed, Dec 02, 2009 at 10:05:51AM -0500, drew Roberts wrote:
>
> > > > Audio data transfer will be via netjack using CELT compression.
> > > Ack.
> > Can CELT also do uncompressed or lossless?
>
> That's called raw PCM. ;)
>
> > Otherwise limiting to CELT might not be such a good idea if I have
> > followed things closely enough.
>
> 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)

the latency is just half a period. but there is no need for this. you
can transmit 100 uncompressed channels via GigE no problem.

well... having it built with celt support wont harm.
and that opens the possibility to connect to a soundcard in another
continent :)

well... note that the CPU should be able to handle the float conversions
in this case. if it doesnt have an FPU and you need to use soft-floats,
the conversions could use a significant share of CPU.


--
torben Hohn

[f***@kokkinizita.net]

On Wed, Dec 02, 2009 at 05:41:12PM +0100, torbenh wrote:

> well... note that the CPU should be able to handle the float conversions
> in this case. if it doesnt have an FPU and you need to use soft-floats,
> the conversions could use a significant share of CPU.

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 ?

[drew Roberts]

On Wednesday 02 December 2009 10:20:45 Adrian Knoth wrote:
> > Can CELT also do uncompressed or lossless?
>
> That's called raw PCM. ;)

Other things can fit the requirements. (Not saying they make sense but...) I
just figured where CELT was called out that perhaps it could go from
uncompressed or lossless to lossy compressed so that you could go either way
with one "format"...

all the best,

drew

[f***@kokkinizita.net]

On Wed, Dec 02, 2009 at 10:05:51AM -0500, drew Roberts wrote:

> Can CELT also do uncompressed or lossless? Otherwise limiting to CELT might
> not be such a good idea if I have followed things closely enough.

>

[Folderol]

On Wed, 2 Dec 2009 17:15:25 +0100
***@kokkinizita.net wrote:

> On Wed, Dec 02, 2009 at 10:05:51AM -0500, drew Roberts wrote:
>
> > Can CELT also do uncompressed or lossless? Otherwise limiting to CELT might
> > not be such a good idea if I have followed things closely enough.
>
>

[Karl Hammar]

fons:
> On Wed, Dec 02, 2009 at 10:05:51AM -0500, drew Roberts wrote:
...
> >

[Jens M Andreasen]

On Mon, 2009-12-07 at 20:41 +0100, Karl Hammar wrote:

> So, 24bit, 48/96kHz is the spec. to aim at?
>

If you happen to sit on a warehouse full of them, otherwise 192kHz is
priced the same these days.

> > I've noted some other strange things. Why should a
> > soundcard be running Linux, or any other OS for that
> > matter ?
>
> It doesn't need to, but it might be easier to use an os when
> developing.

Hey, you already have an OS. This board might be more like it:

http://www.pjrc.com/teensy/

[f***@kokkinizita.net]

On Mon, Dec 07, 2009 at 11:06:23PM +0100, Jens M Andreasen wrote:

> On Mon, 2009-12-07 at 20:41 +0100, Karl Hammar wrote:
>
> > So, 24bit, 48/96kHz is the spec. to aim at?
> >
>
> If you happen to sit on a warehouse full of them, otherwise 192kHz is
> priced the same these days.

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

[Dan Mills]

On Mon, 2009-12-07 at 23:34 +0100, ***@kokkinizita.net 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.

...For audio!

However, I am seeing something being discussed that could potentially
have utility well beyond audio (think instrumentation applications) and
for that use supporting 192 may well be useful.

In fact, even for such mundane things as measuring the out of band noise
in a new DAC design it would be useful.

Regards, Dan (Who likes the ethernet approach, even if it means the card
has to 'pull' frames over the link with the corresponding latency
issues).

[f***@kokkinizita.net]

On Mon, Dec 07, 2009 at 11:02:58PM +0000, Dan Mills wrote:
> On Mon, 2009-12-07 at 23:34 +0100, ***@kokkinizita.net 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.
>
> ...For audio!
>
> However, I am seeing something being discussed that could potentially
> have utility well beyond audio (think instrumentation applications) and
> for that use supporting 192 may well be useful.
>
> In fact, even for such mundane things as measuring the out of band noise
> in a new DAC design it would be useful.

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

[Folderol]

On Mon, 7 Dec 2009 23:34:34 +0100
***@kokkinizita.net wrote:

> On Mon, Dec 07, 2009 at 11:06:23PM +0100, Jens M Andreasen wrote:
>
> > On Mon, 2009-12-07 at 20:41 +0100, Karl Hammar wrote:
> >
> > > So, 24bit, 48/96kHz is the spec. to aim at?
> > >
> >
> > If you happen to sit on a warehouse full of them, otherwise 192kHz is
> > priced the same these days.
>
> 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,

Almost as good as the special speaker cable supports you can get...
that look suspiciously like standard 1100V ceramic insulators :)

--
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.

[Paul Davis]

On Mon, Dec 7, 2009 at 5:34 PM, <***@kokkinizita.net> 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.

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 ??

[Jörn Nettingsmeier]

***@kokkinizita.net wrote:
> On Mon, Dec 07, 2009 at 11:06:23PM +0100, Jens M Andreasen wrote:
>
>> On Mon, 2009-12-07 at 20:41 +0100, Karl Hammar wrote:
>>
>>> So, 24bit, 48/96kHz is the spec. to aim at?
>>>
>> If you happen to sit on a warehouse full of them, otherwise 192kHz is
>> priced the same these days.
>
> But take into account that 192 kHz is the same
> type of marketing scam as gold-plated optical
> connectors. In other words completely useless.

i thought the same, until i happened upon the website of a bat fancier
who is recording his favourite animals with a pimped condenser mic with
extended hf response, and then either uses the sonographic "voiceprints"
to differentiate between species, or pitch-shifts the bat sounds into
the audible range. quite fascinating.

and it makes me think of david monacchi, that italian prof who played
his rainforest archival recordings at the ambi symposium in graz - for
those applications, it might actually make sense (iff you can get that
extended hf out of your signal chain, without excessive radio
interference - a rainforest should be a relatively rf-friendly
environment, if your colleagues keep their mobiles off...)

but yes, for human baseband use, with standard equipment (especially as
a selling proposal in the consumer market), 192kHz remains utter hogwash...

[f***@kokkinizita.net]

On Tue, Dec 08, 2009 at 12:47:32AM +0100, Jörn Nettingsmeier wrote:

> i thought the same, until i happened upon the website of a bat fancier
> who is recording his favourite animals with a pimped condenser mic with
> extended hf response, and then either uses the sonographic "voiceprints"
> to differentiate between species, or pitch-shifts the bat sounds into
> the audible range. quite fascinating.
>
> and it makes me think of david monacchi, that italian prof who played
> his rainforest archival recordings at the ambi symposium in graz - for
> those applications, it might actually make sense (iff you can get that
> extended hf out of your signal chain, without excessive radio
> interference - a rainforest should be a relatively rf-friendly
> environment, if your colleagues keep their mobiles off...)

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

[Folderol]

On Wed, 2 Dec 2009 10:05:51 -0500
drew Roberts <***@100jamz.com> wrote:

> On Tuesday 01 December 2009 13:31:24 Karl Hammar wrote:
> > > --------------------------
> > > Firmware/Software
> > > --------------------------
> > > The device will run Linux OS.
> > > Audio data transfer will be via netjack using CELT compression.
> >
> > Ack.
>
> Can CELT also do uncompressed or lossless? Otherwise limiting to CELT might
> not be such a good idea if I have followed things closely enough.
>
> all the best,
>
> drew

I hadn't spotted that :(
You're right, lossy compression would be a disaster for this project.
Even lossless compression is only an advantage if it can be done in
small enough chunks to not actually increase latency rather than
reduce it.

--
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.

[torbenh]

On Tue, Dec 01, 2009 at 06:22:20PM +1100, Patrick Shirkey wrote:
> --------------------------
> Firmware/Software
> --------------------------
>
> The device will run Linux OS.
> Audio data transfer will be via netjack using CELT compression.

heh ? you dont want lossy compression for a soundcard.
if you only intend to transmit 8 channels you dont need that.


--
torben Hohn

[Michael Chapman]

On Tuesday 01 December 2009 12:55 am, ***@aspodata.se (Karl Hammar) wrote:
> Me too. But I will not maintain webpages. That is open for someone else.

I've just got Plone up on our server.

It allows multiple/cooperative authoring/editing/interchange.
I'm still experimenting with it, but picking up speed . . .

Michael

[Adrian Knoth]

On Tue, Dec 01, 2009 at 09:20:07AM +1100, Patrick Shirkey wrote:

Hi!

> How many chipsets come with support for adat or firewire ootb? I have

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&id=12&Itemid=10


HTH

--
mail: ***@thur.de http://adi.thur.de PGP/GPG: key via keyserver

[Karl Hammar]

Adrian Knoth:
> On Tue, Dec 01, 2009 at 09:20:07AM +1100, Patrick Shirkey wrote:
> > How many chipsets come with support for adat or firewire ootb? I have
> 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&id=12&Itemid=10

Hello Adrian and thank you for the link, it seems to be an
interesting chip.

To bad it does not have an ethernet interface. Maybe one can use
one of the micrel chips below (there is drivers in the kernel for
them at least) ?

But if the network interface can be solved it could be a good
solution for your adat - ethernet idéa [2].

Or..

Maybe one can use it together with another processor.

Regards,
/Karl

[1]
http://www.micrel.com/_PDF/Ethernet/ethernet_datasheet/KSZ8842MQL_DS.pdf
http://www.micrel.com/_PDF/Ethernet/ethernet_datasheet/ksz8851-16mll_ds.pdf
http://www.micrel.com/_PDF/Ethernet/ethernet_datasheet/ksz8851-mql_ds.pdf
http://www.micrel.com/_PDF/Ethernet/ethernet_datasheet/ksz8851snl_ds.pdf

[2] http://lists.linuxaudio.org/pipermail/linux-audio-dev/2009-November/025687.html

-----------------------------------------------------------------------
Karl Hammar Aspö Data ***@aspodata.se
Lilla Aspö 148 Networks
S-742 94 Östhammar [phone] Computers
Sweden [phone] Consulting
-----------------------------------------------------------------------

[Pieter Palmers]

Karl Hammar wrote:
> Adrian Knoth:
>> On Tue, Dec 01, 2009 at 09:20:07AM +1100, Patrick Shirkey wrote:
>>> How many chipsets come with support for adat or firewire ootb? I have
>> 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&id=12&Itemid=10
>
> Hello Adrian and thank you for the link, it seems to be an
> interesting chip.
>
> To bad it does not have an ethernet interface. Maybe one can use
> one of the micrel chips below (there is drivers in the kernel for
> them at least) ?
>
> But if the network interface can be solved it could be a good
> solution for your adat - ethernet idéa [2].

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=45&Itemid=37

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]

Pieter Palmers:
> Karl Hammar wrote:
> > Adrian Knoth:
...
> >> only chip I know, and luckily, it supports ADAT and Firewire. ;)
> >> http://www.tctechnologies.tc/index.php?option=com_content&view=article&id=12&Itemid=10
...
> > But if the network interface can be solved it could be a good
> > solution for your adat - ethernet idéa [2].
> 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=45&Itemid=37

It does not seem to help Adrian with his interest in ADAT.

> This has onboard ethernet and USB (at 480Mbit), and runs linux.

Ok, this one is better for your usb wish.

> 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.

Yes, it seems to have a lot of audio capability. It would be even
nicer if it did have usb and ethernet.

On the downside, at least for me, is that I have no use for it in my
other project, so I can't share that much between projects. The best
thing for me would be to "just add a soundcard" (except the soundcard).

On could possible add an fpga, but that is a long way to go.

Soo, I think that I'll "just add and soundcard" to my original
project and anyone is welcome to participate in that project.

And we discuss the possibility to create a new audio-only project,
and what it should deliver. That also frees us from any form factors
or requirements from the other project. In this possible new project
others than me must step forward and take the lead, but I am willing
to help out where I can. Then we can see what can be shared between
projects.

...
> But there are plenty of
> technical reasons to choose firewire over ethernet (or USB).

Well, tell us, it will be good to have that documented in a rationale.

Regards,
/Karl

-----------------------------------------------------------------------
Karl Hammar Aspö Data ***@aspodata.se
Lilla Aspö 148 Networks
S-742 94 Östhammar [phone] Computers
Sweden [phone] Consulting
-----------------------------------------------------------------------

[Pieter Palmers]

Karl Hammar wrote:
> Pieter Palmers:
>> Karl Hammar wrote:
> ...
>> But there are plenty of
>> technical reasons to choose firewire over ethernet (or USB).
>
> Well, tell us, it will be good to have that documented in a rationale.
>

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.

[Gene Heskett]

On Sunday 06 December 2009, Pieter Palmers wrote:
[...]

>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.

At the expense of a truly horrible latency built into the usb specs. In
another field (my interests are best described as eclectic), involving far
less data at a time than audio, machine control, aka cnc milling and similar
operations where the machine must be under the computers control at sub-
millisecond intervals for servo's and < 50 microsecond intervals for stepper
motors, those who have tried to go down the usb road have generally failed
rather miserably. So that road is both well traveled and has been found
wanting. 100 millisecond latency's just cannot be tolerated for that usage.

Ethernet is everywhere, and is one of the reasons my previous messages
favored it. Unforch, while I grant that firewire is hands down superior, and
I have a couple of ports here, it is apparently a totally daisy chain
topology from a single host port, and AIUI, cable lengths are very limited
in comparison to ethernet. However there is a 6 port 'hub' at
<http://www.firewire-1394.com/firewire-hub-fw106.htm> ($38.99)
to expand the limited number (usually 1 or 2) of ports found on todays
motherboards, and the total cable length to 9 meters, and even the pluggin
cards available seem to be limited to 4 ports. I see that for 1394b, cables
up to 32 feet are available but at the price I'd have to assume there is a
booster hub in the middle. With pricy optical convertors, to 3/8's mile
using glass fiber. (actually it is probably plastic if it has that length
limitation, glass, good glass, checked out at .4 db loss over 39 kilometers
when we fed the local cable systems from our studios, several years ago now.

ATM out of 6 mobo USB ports and 6 hubs making branches as deep as 4 sub-hubs,
I have only 7 open sockets. And I don't believe my usb map is anywhere near
a record setter.

Were there a firewire audio gizmo on site, I might have it working too, so go
build one, I'm waiting. (and don't forget the daisy chain, most folks ignore
it) The first port here is for my movie camera, which kino generally runs
quite nicely, with very nearly realtime video and audio, only a slight echo
between the speaker on the camera and my speakers. :)

--
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>

<krogoth> Kgnghtbrd: I wouldn't kow, I see no need for a spellchecker yet
<Knghtbrd> you were saying?

[Patrick Shirkey]

On 12/07/2009 05:36 AM, Gene Heskett wrote:
>
> ATM out of 6 mobo USB ports and 6 hubs making branches as deep as 4 sub-hubs,
> I have only 7 open sockets. And I don't believe my usb map is anywhere near
> a record setter.
>
>

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

[Gene Heskett]

On Sunday 06 December 2009, Patrick Shirkey wrote:
>On 12/07/2009 05:36 AM, Gene Heskett wrote:
>> ATM out of 6 mobo USB ports and 6 hubs making branches as deep as 4
>> sub-hubs, I have only 7 open sockets. And I don't believe my usb map is
>> anywhere near a record setter.
>
>Slightly off topic but...
>
Whats a 'topic' Patrick? :)

>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.
>

And those chips ident themselves as?

>My experience with usb cable lengths > 3 meters is that they require a
>booster.

Which is generally seen as a hub in an lsusb, they just don't socket out the
other 3 ports. I had 2 of the FDTI versions, but the far end wasn't exactly
on the same circuit, and a wandering lightning strike took one of them out,
so now I have a powered hub plugged into the remaining good extension cable
with 3 of its ports in use when an eldlerly coco3 is powered up, and that has
been working nicely for about a year now. All my usb-serial stuff is FDTI,
the pl2303 stuff is pure crap as we found on the heyu mailing list.

I'm glad to hear Belkin stuff is working well, but I'd almost expect that
since they had a heavy hand in the original USB specs. Too bad their UPS's
don't adhere to it.

Its also worth note that Belkin has a real and obnoxious screw you attitude
about linux over in the UPS division. They make, or relabel, a darned good
UPS, and it would be very nice if we could actually talk to it from linux.
Unforch, their latest monitor software, BullDog, was built on an RH-5.2
system, and turns into a 100% of all cores cpu hog on a 2.4 or 2.6 SMP
kernel.

Attempts to get them to rebuild it for newer linux's have been made,
including giving us the src so we can. Their return msgs will answer every
question with boilerplate, except about the BullDog software for linux, those
questions are trimmed from the replies and ignored. Obviously my next UPS
when these batteries have failed will have a label on it that is known linux
friendly, like APC.

>Patrick Shirkey
>Boost Hardware Ltd

--
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>

Better to be nouveau than never to have been riche at all.

[Folderol]

On Tue, 01 Dec 2009 09:20:07 +1100
Patrick Shirkey <***@boosthardware.com> wrote:

>
> On 12/01/2009 12:46 AM, Karl Hammar wrote:
> > ***@boosthardware.com:
> >
> >> On 11/29/2009 03:36 PM, Ken Restivo wrote:
> >>
> >>> On Tue, Nov 24, 2009 at 10:33:45AM +0100, Karl Hammar wrote:
> >>>
> > ...
> >
> >>>> My goals is "just" to extend another project (industrial i/o).
> >>>> What would your goals be ?
> >>>>
> > ...
> >
> >>> The original thread converged on a goal pretty quickly: an
> >>> inexpensive, multi-channel audio interface which is open hardware and
> >>> software, and uses Gig Ethernet as its physical connection method.
> >>>
> > ...
> >
> >> Did anyone have a good reason for not including support for a
> >> usb-1.0/2.0/3.0 interface seeing as we can write the driver ourselves
> >> and adhere to the standard?
> >>
> > The usual open source reasons, time and interest, and maybe money.
> >
> > If someone provides the usb-knowledge (or firewire, adat, ... etc.)
> > I'd be happy to have it included, and I assume others would not mind.
> > Or, others might include it. I encourage people do their own versions.
> >
> >
>
>
> 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?
>
> >> Most chipsets these days have support for both port types. It would be
> >> very useful if the schematic provided tracks for both ootb.
> >>
> > It should be doable, please tell us what components to inlucde.
> >
>
>
> I'll get back to you on this.
>
>
> >
> >> BTW, I will be able to contribute development funds towards this project
> >> if required once we have a BoM.
> >>
> > I think the most valueable contributions would be
> >
> > . a good set of specs to aim at (I cannot provide that)
> >
>
>
> 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.

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 :(

>
> > . hw and sw knowledge
> >
>
> Of course.
>
>
> > . testing and evaluation, and equipment for that
> >
>
>
> I have an oscilliscope and some other random hardware for testing with.

My new millivoltmeter/dB meter is nearly finished - All I need now is
precision resistors 9M, 900k, 90k :?

> > . prototype boards for testers
> > . components, chips and mundane things like that
> >
>
> 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.
>
> > . cummunication, git-repo, webserver, mailing list, ...
> >
>
> I have a server to use for this or we can go with one of the many
> existing free services.
>
>
> > If someone wish to contract me to work on this, I'd be happy, but
> > that is not a requirement.
> >
> >
>
> I can contribute funds but cannot afford to fund the project completely.
>
>
>
> Patrick Shirkey
> Boost Hardware Ltd

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.

[Karl Hammar]

Folderol:
...
> My new millivoltmeter/dB meter is nearly finished - All I need now is
> precision resistors 9M, 900k, 90k :?
...

Can you publicise it so I can build me one also?

Regards,
/Karl

-----------------------------------------------------------------------
Karl Hammar Aspö Data ***@aspodata.se
Lilla Aspö 148 Networks
S-742 94 Östhammar [phone] Computers
Sweden [phone] Consulting
-----------------------------------------------------------------------

[Folderol]

On Tue, 1 Dec 2009 21:46:32 +0100 (CET)
***@aspodata.se (Karl Hammar) wrote:

> Folderol:
> ...
> > My new millivoltmeter/dB meter is nearly finished - All I need now is
> > precision resistors 9M, 900k, 90k :?
> ...
>
> Can you publicise it so I can build me one also?
>
> Regards,
> /Karl

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.

[Folderol]

On Wed, 2 Dec 2009 17:19:30 +0000
Folderol <***@ukfsn.org> wrote:

> On Tue, 1 Dec 2009 21:46:32 +0100 (CET)
> ***@aspodata.se (Karl Hammar) wrote:
>
> > Folderol:
> > ...
> > > My new millivoltmeter/dB meter is nearly finished - All I need now is
> > > precision resistors 9M, 900k, 90k :?
> > ...
> >
> > Can you publicise it so I can build me one also?
> >
> > Regards,
> > /Karl
>
> 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.

As promised, PDF attached.
I haven't had time to make out any explanatory notes, but I think it's
pretty straight forward anyway

0dB is variable so it can be set to whatever is convenient, hence
temperature drift from using an ordinary diode as a reference is not
important.

--
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.

[f***@kokkinizita.net]

On Thu, Dec 03, 2009 at 10:29:54PM +0000, Folderol wrote:

> As promised, PDF attached.

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 ?

[Folderol]

On Thu, 3 Dec 2009 23:52:03 +0100
***@kokkinizita.net wrote:

> On Thu, Dec 03, 2009 at 10:29:54PM +0000, Folderol wrote:
>
> > As promised, PDF attached.
>
> 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.

I use the old fashioned method of wiring resistors directly on
standard glass loaded wafer switches. Initial tests suggest the
bandwidth well exceeds 20kHz - as opposed to less than 1kHz for many
quite expensive commercial units.

> 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 ?

No reason at all, except that being a cheapskate I was able to
convince the boss that a good true RMS meter would be useful in the
workshop :)

A 10M input is more-or-less mandatory in this case, but anyone else
should feel free to make the ladder impedance whatever they like.

--
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.

[f***@kokkinizita.net]

On Thu, Dec 03, 2009 at 11:13:05PM +0000, Folderol wrote:

> I use the old fashioned method of wiring resistors directly on
> standard glass loaded wafer switches. Initial tests suggest the
> bandwidth well exceeds 20kHz - as opposed to less than 1kHz for many
> quite expensive commercial units.

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.

> A 10M input is more-or-less mandatory in this case, but anyone else
> should feel free to make the ladder impedance whatever they like.

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

[Tracey Hytry]

Looking at the pdf, the voltmeter looks functional.
Maybe the front end can be tweaked, but this a problem of most test instruments.
Last I saw, good probes that match a decent input cost a lot of money; maybe more then the voltmeter in this case.
Anyway, thanks for the schematic Will. And thanks for the (somewhat)constructive help on the circuit Fons.

[Folderol]

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 ***@kokkinizita.net wrote:

> On Thu, Dec 03, 2009 at 11:13:05PM +0000, Folderol wrote:
>
> > I use the old fashioned method of wiring resistors directly on
> > standard glass loaded wafer switches. Initial tests suggest the
> > bandwidth well exceeds 20kHz - as opposed to less than 1kHz for many
> > quite expensive commercial units.
>
> They are not so 'standard' today, and probably difficult
> to find.

http://uk.rs-online.com/web/search/searchBrowseAction.html?method=getProduct&R=0352250

Cheap modern equivalent, although a bit smaller.

http://uk.rs-online.com/web/search/searchBrowseAction.html?method=getProduct&R=0327585

Very expensive 'full size' switch. Unfortunately only available as BBM
- I prefer MBB for sensitive input stuff.

> 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.

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.

[f***@kokkinizita.net]

On Fri, Dec 04, 2009 at 07:41:56PM +0000, Folderol wrote:

> 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.

Compared to the 0.1% spec on the resistors these are
big errors. 1dB is 12%. 0.1% is less than 0.01dB.

A reasonable target would be 1% accuracy, that is less
that 0.1dB.

Ciao,

--
FA

Wie der Mond heute Nacht aussieht !
Ist es nicht ein seltsames Bild ?

[drew Roberts]

On Thursday 03 December 2009 18:13:05 Folderol wrote:
> 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.

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

[Karl Hammar]

Adrian Knoth:
> On Mon, Nov 23, 2009 at 08:28:03PM +0000, Folderol wrote:
>
> > The rationale in brief:
> > No proprietry hardware soundcard needed.
> > Almost all modern computers have reasonably fast Ethernet connections.
>
> Don't know how much you already did for the hardware layout. If
> possible, try to avoid analog stuff, that is, ADC/DAC.

You don't say why we should avoid analog stuff.
For me the whole point of doing this is the analog stuff.

...
> I'm also somewhat interested in the network part, I feel IPv6 could help
> a lot. It supports autoconfiguration and it has decent multicast
> support, so it would be possible to broadcast/multicast the streams on
> the net (LAN). This could be useful if you want to access the stream at
> a mixing console for a life setup and simultaneously record it on a
> computer.

At a live recording you probably have only your own gear connected to
the lan. In that case you can easily assign ip-adresses at will and to
your own taste. I don't see how IPv6 vs. IPv4 could matter at all.

> That's basically what Roland's Digital Snake offers: an onstage Ethernet
> (not IP) soundcard and one or more remote devices. RockNet provides
> similar stuff, there's also Ethersound, but RockNet is PC-incompatible
> (400MBit/s proprietary protocol), Roland is undocumented and I don't
> know nothing about Ethersound. ;)

That tells us that it should be doable. But of cause we want an open
protocol. Do you know the capacity limits of thoose systems ?

> I also have some fancy Xilinx boards with onboard ethernet, an audio
> codec (including the analog jacks) and a FPGA. Though it's way harder to
> mimic all the features with VHDL, it could provide stable timings. The
> boards also support memory, so it would be possible to load a softcore
> and run Linux on them.

Doing things with a fpga would certainly be interesting, but I cannot
do it for the moment. Perhaps you could provide designs we could
include...

> If you like, feel free to Cc me or join #lad if you think I could
> contribute something.

I assume you are on the list, so I only send on the list.

Regards,
/Karl

-----------------------------------------------------------------------
Karl Hammar Aspö Data ***@aspodata.se
Lilla Aspö 148 Networks
S-742 94 Östhammar [phone] Computers
Sweden [phone] Consulting
-----------------------------------------------------------------------

[Adrian Knoth]

On Tue, Nov 24, 2009 at 09:48:53AM +0100, Karl Hammar wrote:
> So ich habe mal was zusammengedichtet ....
> > > The rationale in brief:
> > > No proprietry hardware soundcard needed.
> > > Almost all modern computers have reasonably fast Ethernet connections.
> > Don't know how much you already did for the hardware layout. If
> > possible, try to avoid analog stuff, that is, ADC/DAC.
> You don't say why we should avoid analog stuff.

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.

> > I'm also somewhat interested in the network part, I feel IPv6 could help
> > a lot. It supports autoconfiguration and it has decent multicast
> > support, so it would be possible to broadcast/multicast the streams on
> > the net (LAN). This could be useful if you want to access the stream at
> > a mixing console for a life setup and simultaneously record it on a
> > computer.
> At a live recording you probably have only your own gear connected to
> the lan. In that case you can easily assign ip-adresses at will and to
> your own taste. I don't see how IPv6 vs. IPv4 could matter at all.

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]
> That tells us that it should be doable. But of cause we want an open
> protocol. Do you know the capacity limits of those systems?

Approximately what you could expect from a 100MBit/s link. At least 32
channels, rocknet even more, but they use 400MBit/s.


Cheerio

--
mail: ***@thur.de http://adi.thur.de PGP/GPG: key via keyserver

[Karl Hammar]

Adrian Knoth:
> On Tue, Nov 24, 2009 at 09:48:53AM +0100, Karl Hammar wrote:
> > So ich habe mal was zusammengedichtet ....
> > > > The rationale in brief:
> > > > No proprietry hardware soundcard needed.
> > > > Almost all modern computers have reasonably fast Ethernet connections.
> > > Don't know how much you already did for the hardware layout. If
> > > possible, try to avoid analog stuff, that is, ADC/DAC.
> > You don't say why we should avoid analog stuff.
>
> 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.

My goal is not to compete with high quality manufacturer, it is to see
how far this takes us. Others might have other goals.

> 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.

I don't have any adat equipment, so I cannot test it, but if anyone
else is willing I might give it a try. Do you have any specific chips
in mind?

> [...list of adat converters...]
> 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.

Well, you have to start somewhere. I'm not in this to compete with
Behringer ADA8000, I'm in this to fiddle around with soldering.

> 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

That one is clearly out of my shopping range.
But talking about RME we have:

http://www.thomann.de/gb/rme_quadmic.htm

which is in an more affordable price range, no I don't know how good it
is.

> 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. ;)

Then this project might not be for thoose people. Let's face there are
"always" someone else that is better than me/you at this or that thing.
I will be perfectly happy if this project stops at some noisy 64channel
16bit 44.1 kHz thing with working protocols, because then someone else
migth take it further.

> 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.

If someone lends me/us gear to test on and a spec to work from, links
to chips to use, preferrable some chips also, does some testing and
encouraging, I might be able to help. Otherwise it is simply out of budget.

One question tough. If you have ADAT, why go the longer way over an
ADAT-to-ethernet box than straight into your adat card in your computer?
What would one gain?

> > > I'm also somewhat interested in the network part, I feel IPv6 could help
> > > a lot. It supports autoconfiguration and it has decent multicast
> > > support, so it would be possible to broadcast/multicast the streams on
> > > the net (LAN). This could be useful if you want to access the stream at
> > > a mixing console for a life setup and simultaneously record it on a
> > > computer.
> > At a live recording you probably have only your own gear connected to
> > the lan. In that case you can easily assign ip-adresses at will and to
> > your own taste. I don't see how IPv6 vs. IPv4 could matter at all.
>
> 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

I don't have any problem with that feeling.

> and increases complexity.

I don't mind this one time configuration.

> 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).

You could hack a similar thing into theese devices if you wish.

uint48_t ethernet_addr;
uint32_t ip_addr = 192 << 24 | 168 << 16 | ethernet_addr & 0xffff;

> No need to assign anything, you're instantly ready to go.

You do need to know which box is which, if it is only the local
workstation and the I/O box - ok, but if you have more than two
devices you need to know which one you are talking to. So, if you
take ten devices right out the boxes and puts them on the net,
you have to do "something" to know which cable goes where.

Some proposals to do this could be:
. do something on "master" and a led lights up on the slave
. read off some code or serial number on the device and match it to one
in your list
. do something to the slave (like talking into a connected mic) and see
response on master
. assign name/address in a 1990'th style

Well, we could provide for all thoose possibilities, since we all have
different preferences.

> 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.

Yes, I see no functional difference IPv4 - IPv6.

> 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)

I personally don't need to find my devices, I already know about them.

> In other words: A single address is sufficient to trigger the callbacks.

One could make the devices respond to a broadcast ping wich gives you
the same functionality in IPv4.

> 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.

Don't get me wrong, I'd be happy to make it work with IPv6, and we can
make it ipv6 only, I would not mind.

Maybe someone like you could do the ipv6 testing.

> 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)

That is another question we are not yet prepared to tackle.

> [RockNet, Roland Digital Snake, Ethersound]
> > That tells us that it should be doable. But of cause we want an open
> > protocol. Do you know the capacity limits of those systems?
>
> Approximately what you could expect from a 100MBit/s link. At least 32
> channels, rocknet even more, but they use 400MBit/s.

Yes, but the devil is in the details as always. Having a working
example is as usual an working example. And we are missing an open
protocol for this.

Regards,
/Karl

-----------------------------------------------------------------------
Karl Hammar Aspö Data ***@aspodata.se
Lilla Aspö 148 Networks
S-742 94 Östhammar [phone] Computers
Sweden [phone] Consulting
-----------------------------------------------------------------------

[Florian Faber]

Karl Hammar wrote:

>> [RockNet, Roland Digital Snake, Ethersound]
>>> That tells us that it should be doable. But of cause we want an open
>>> protocol. Do you know the capacity limits of those systems?
>> Approximately what you could expect from a 100MBit/s link. At least 32
>> channels, rocknet even more, but they use 400MBit/s.
> Yes, but the devil is in the details as always. Having a working
> example is as usual an working example. And we are missing an open
> protocol for this.

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

[Karl Hammar]

Florian Faber:
> Karl Hammar wrote:
> > [..ethernet transports..]
> > And we are missing an open protocol for this.
> 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.

Ohh, sorry, I got the impression it was not ready. I don't mind being
wrong in that.

Regards,
/Karl

-----------------------------------------------------------------------
Karl Hammar Aspö Data ***@aspodata.se
Lilla Aspö 148 Networks
S-742 94 Östhammar [phone] Computers
Sweden [phone] Consulting
-----------------------------------------------------------------------

[torbenh]

On Tue, Nov 24, 2009 at 08:34:53PM +0100, Karl Hammar wrote:
> Florian Faber:
> > Karl Hammar wrote:
> > > [..ethernet transports..]
> > > And we are missing an open protocol for this.
> > 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.
>
> Ohh, sorry, I got the impression it was not ready. I don't mind being
> wrong in that.

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

[Folderol]

On Thu, 26 Nov 2009 06:36:07 +0100
torbenh <***@gmx.de> wrote:

> On Tue, Nov 24, 2009 at 08:34:53PM +0100, Karl Hammar wrote:
> > Florian Faber:
> > > Karl Hammar wrote:
> > > > [..ethernet transports..]
> > > > And we are missing an open protocol for this.
> > > 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.
> >
> > Ohh, sorry, I got the impression it was not ready. I don't mind being
> > wrong in that.
>
> 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.

I'm not sure why, but I had an impression of 'unreadiness' too :o

> 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 !!!

The remaining issue then is how much additional latency does netjack
introduce? I think, eventually, this will turn out to be the most
critical issue.

> 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.

If there is no internal sound card, why is there any need for alsa?

Wordlock may not be as difficult as it first seems. A bit I originally
wrote to LAU...

> 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.

Even without this, I wonder what the audible effect on real music would
be of just dropping one sample per second. It might be worth doing some
experiments to find out.

It also occurs to me that although we want to lock frequency, phase
relationship between cards is a red herring. Signals from different
sources will not have any phase relationship, so why should the cards?

--
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.

[torbenh]

On Thu, Nov 26, 2009 at 08:55:50AM +0000, Folderol wrote:
> On Thu, 26 Nov 2009 06:36:07 +0100
> torbenh <***@gmx.de> wrote:
>
> > On Tue, Nov 24, 2009 at 08:34:53PM +0100, Karl Hammar wrote:
> > > Florian Faber:
> > > > Karl Hammar wrote:
> > > > > [..ethernet transports..]
> > > > > And we are missing an open protocol for this.
> > > > 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.
> > >
> > > Ohh, sorry, I got the impression it was not ready. I don't mind being
> > > wrong in that.
> >
> > 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.
>
> I'm not sure why, but I had an impression of 'unreadiness' too :o

:S great.
did you try it, and it didnt work ?


>
> > 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 !!!
>
> The remaining issue then is how much additional latency does netjack
> introduce? I think, eventually, this will turn out to be the most
> critical issue.

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.


>
> > 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.
>
> If there is no internal sound card, why is there any need for alsa?
>
> Wordlock may not be as difficult as it first seems. A bit I originally
> wrote to LAU...

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.


>
> > 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.
>
> Even without this, I wonder what the audible effect on real music would
> be of just dropping one sample per second. It might be worth doing some
> experiments to find out.

i dont understand why you want that...


> It also occurs to me that although we want to lock frequency, phase
> relationship between cards is a red herring. Signals from different
> sources will not have any phase relationship, so why should the cards?

alsa_out is able to deliver that.
>
> --
> 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-***@lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language

[Hans Wilmers]

torbenh wrote:
> On Tue, Nov 24, 2009 at 08:34:53PM +0100, Karl Hammar wrote:
>
>> Florian Faber:
>>
>>> Karl Hammar wrote:
>>>
>>>> [..ethernet transports..]
>>>> And we are missing an open protocol for this.
>>>>
>>> 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.
>>>
>> Ohh, sorry, I got the impression it was not ready. I don't mind being
>> wrong in that.
>>
>
> 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.
>
>
Would it be easy to use netjack also without jack running on the network
soundcard?

/ Hans


--
Hans Wilmers
NOTAM
Nedre Gate 5
N-0551 Oslo Norway
tlf.: [phone]
http://www.notam02.no

[Karl Hammar]

torbenh:
> On Tue, Nov 24, 2009 at 08:34:53PM +0100, Karl Hammar wrote:
> > Florian Faber:
...
> > > What is wrong with netjack? It's made for point-to-point and very
...
> > Ohh, sorry, I got the impression it was not ready. I don't mind being
> > wrong in that.
> may i kindly ask what gave you that impression ?

"...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.html

"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.html

...
> but the lan use-case it pretty trivial and doesnt need all this deadline
> machinery.

Ok.

> if you just want to build a network soundcard, and use jack on a
> computer with that, its ready for 3 years now !!!

Great, good news.

> 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.

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 ***@aspodata.se
Lilla Aspö 148 Networks
S-742 94 Östhammar [phone] Computers
Sweden [phone] Consulting
-----------------------------------------------------------------------

[Adrian Knoth]

On Tue, Nov 24, 2009 at 04:46:02PM +0100, Karl Hammar wrote:

> Well, you have to start somewhere. I'm not in this to compete with
> Behringer ADA8000, I'm in this to fiddle around with soldering.

WTF? Soldering is what it takes to make the product. If soldering is the
motivation for the project, I couldn't care less. ;)

OTOH, as Gene has pointed out, a completely open source protocol
replacing ADAT is a valid motivation, so the HQ guys could still jump
the band waggon once the protocol has settled.

(given that it will ever make its way)

> One question tough. If you have ADAT, why go the longer way over an
> ADAT-to-ethernet box than straight into your adat card in your computer?
> What would one gain?

I could then place multiple ADAT converters on the net, combine their
capacity without using MADI (64 channels over one cable), copy the
signal at the FOH (front-of-house, mixing desk), feed every musician
with his personal monitoring stream and record it.

Today, RockNet does this, all audio distribution networks do this, but
they are expensive. My impression was you want to provide this kind of
functionality for less money.

If I could save the MADI card and just plug the network cable into my
el-cheapo network card, I would have a gain.


> uint48_t ethernet_addr;
> uint32_t ip_addr = 192 << 24 | 168 << 16 | ethernet_addr & 0xffff;

I'd probably slap you when come up with code like this. ;) This is
lacking abstraction.

For those who haven't heard, yet: An IP address isn't an uint32_t. This
is the road to hell, leads to unportable code.

But since I'm working for the networking chair at Jena University, let
me tell you that the right structure for an IP address is

struct sockaddr_storage

Nothing else. Don't even dare to shift bits in an uint32_t. Things like
this might have been right in the 90ties, but we had RFC 3493 in
February 2003 (and RFC 2553 in 1999). ;) (things might be different when
we're talking kernel level)


As mentioned in the original posting: if I could provide some input, I'd
happily do this. It's probably a good idea to decide on the goals,
first, but I might have missed that part of the discussion.


Cheerio

--
mail: ***@thur.de http://adi.thur.de PGP/GPG: key via keyserver

[Gene Heskett]

On Tuesday 24 November 2009, Adrian Knoth wrote:
>On Tue, Nov 24, 2009 at 04:46:02PM +0100, Karl Hammar wrote:
>> Well, you have to start somewhere. I'm not in this to compete with
>> Behringer ADA8000, I'm in this to fiddle around with soldering.
>
>WTF? Soldering is what it takes to make the product. If soldering is the
>motivation for the project, I couldn't care less. ;)

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.

>OTOH, as Gene has pointed out, a completely open source protocol
>replacing ADAT is a valid motivation, so the HQ guys could still jump
>the band waggon once the protocol has settled.
>
>(given that it will ever make its way)

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. :)

>> One question tough. If you have ADAT, why go the longer way over an
>> ADAT-to-ethernet box than straight into your adat card in your computer?
>> What would one gain?

Don't have the ADAT, so I cannot begin to answer that in a sensible way.

>I could then place multiple ADAT converters on the net, combine their
>capacity without using MADI (64 channels over one cable), copy the
>signal at the FOH (front-of-house, mixing desk), feed every musician
>with his personal monitoring stream and record it.

At what cost in ADAT capable boxes?

>Today, RockNet does this, all audio distribution networks do this, but
>they are expensive. My impression was you want to provide this kind of
>functionality for less money.

Eggzactly. Lowest common denominator.

>If I could save the MADI card and just plug the network cable into my
>el-cheapo network card, I would have a gain.
>
>> uint48_t ethernet_addr;
>> uint32_t ip_addr = 192 << 24 | 168 << 16 | ethernet_addr & 0xffff;
>
>I'd probably slap you when come up with code like this. ;) This is
>lacking abstraction.
>
>For those who haven't heard, yet: An IP address isn't an uint32_t. This
>is the road to hell, leads to unportable code.

Thanks for pointing that out.

>But since I'm working for the networking chair at Jena University, let
>me tell you that the right structure for an IP address is
>
> struct sockaddr_storage
>
>Nothing else. Don't even dare to shift bits in an uint32_t. Things like
>this might have been right in the 90ties, but we had RFC 3493 in
>February 2003 (and RFC 2553 in 1999). ;) (things might be different when
>we're talking kernel level)
>
>
>As mentioned in the original posting: if I could provide some input, I'd
>happily do this. It's probably a good idea to decide on the goals,
>first, but I might have missed that part of the discussion.

I think this might be the beginnings of _that_ discussion.

>Cheerio

--
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

[Karl Hammar]

Adrian Knoth:
> On Tue, Nov 24, 2009 at 04:46:02PM +0100, Karl Hammar wrote:
> > Well, you have to start somewhere. I'm not in this to compete with
> > Behringer ADA8000, I'm in this to fiddle around with soldering.
> WTF? Soldering is what it takes to make the product. If soldering is the
> motivation for the project, I couldn't care less. ;)

If you don't care, please don't comment.

> OTOH, as Gene has pointed out, a completely open source protocol
> replacing ADAT is a valid motivation, so the HQ guys could still jump
> the band waggon once the protocol has settled.

Has I ever said I'm doing this for the HQ guys? If they want me to
do it, I'd be more than happy to do a bussiness deal with them.

> (given that it will ever make its way)

If you are not interested, please go away.

> > One question tough. If you have ADAT, why go the longer way over an
> > ADAT-to-ethernet box than straight into your adat card in your computer?
> > What would one gain?
...
> If I could save the MADI card and just plug the network cable into my
> el-cheapo network card, I would have a gain.

So, for you, this is about equipment cost, I'm I right?

> > uint48_t ethernet_addr;
> > uint32_t ip_addr = 192 << 24 | 168 << 16 | ethernet_addr & 0xffff;
>
> I'd probably slap you when come up with code like this. ;) This is
> lacking abstraction.

I don't accept your slap even if you add a smiley. This is not about
writing to a socket in an transport agnostic way, this is to show that
a the link local address thing is really easy to implement. Nothing more
nothing less. If you haven't listend closely enougth, this was to show
that you can do the same thing in IPv4 as in IPv6.

> For those who haven't heard, yet: An IP address isn't an uint32_t. This
> is the road to hell, leads to unportable code.

Well, this was about an IPv4 address. I did not use "struct in_addr"
or "in_addr_t", simply because to show that there is no magic to this.

Somewhere you have to do the bitstuffing. And if you already
understand things like this, how would you implement the link local
address in IPv6?

> But since I'm working for the networking chair at Jena University, let
> me tell you that the right structure for an IP address is
>
> struct sockaddr_storage

So that means that if you didn't work at the networking chair,
I would be free to ignore you?

>
> Nothing else. Don't even dare to shift bits in an uint32_t.
...

And mr. networking char at Jena University, don't disgrace the
university with your "slap you", "let me tell you" and "don't even
dare". Continue like this and I will simply ignore you.

Regards,
/Karl

-----------------------------------------------------------------------
Karl Hammar Aspö Data ***@aspodata.se
Lilla Aspö 148 Networks
S-742 94 Östhammar [phone] Computers
Sweden [phone] Consulting
-----------------------------------------------------------------------

[Adrian Knoth]

On Tue, Nov 24, 2009 at 08:35:10PM +0100, Karl Hammar wrote:

> > > uint32_t ip_addr = 192 << 24 | 168 << 16 | ethernet_addr & 0xffff;
> nothing less. If you haven't listend closely enougth, this was to show
> that you can do the same thing in IPv4 as in IPv6.

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.


> Somewhere you have to do the bitstuffing. And if you already
> understand things like this, how would you implement the link local
> address in IPv6?

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).

> > struct sockaddr_storage
> So that means that if you didn't work at the networking chair,
> I would be free to ignore you?

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: ***@thur.de http://adi.thur.de PGP/GPG: key via keyserver

[Michael Chapman]

On Wednesday 25 November 2009 9:22 am, Adrian Knoth wrote:
> I'm happy to go away and not bother you with the progress network
> programming made during the last 10 years.

The devil is in "programming" . . . networking is still stuck in the last
Century. There are clear political reasons for that, but here is not the
place . . .

Yes, if code can cover both 4 and 6 that is great. Code should do that
wherever possible, of course.

But 6 has (thus far) failed . . . in terms of take up. Expecting users to
grapple with 6 for intramural networking when they are familiar with 4 for
extramural is an ?unnecessary burden. (Code, see above, is obviously another
matter.)

Michael

[Karl Hammar]

Adrian Knoth:
> On Tue, Nov 24, 2009 at 08:35:10PM +0100, Karl Hammar wrote:
> > ...
> ...
> I'm happy to go away and not bother you with the progress network
> programming made during the last 10 years.

The world is not black and white. My only point was that for this
application I see no real difference between IPv4 and IPv6.

> 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.

Yes, it occurred to me also (I always turns it off:).

... [ some ancient code ]
> New code shouldn't do this anymore, hence the rude reflex. My apologies.

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 ***@aspodata.se
Lilla Aspö 148 Networks
S-742 94 Östhammar [phone] Computers
Sweden [phone] Consulting
-----------------------------------------------------------------------

[Folderol]

On Tue, 24 Nov 2009 16:46:02 +0100 (CET)
***@aspodata.se (Karl Hammar) wrote:

> Adrian Knoth:
> > On Tue, Nov 24, 2009 at 09:48:53AM +0100, Karl Hammar wrote:
> > > So ich habe mal was zusammengedichtet ....
> > > > > The rationale in brief:
> > > > > No proprietry hardware soundcard needed.
> > > > > Almost all modern computers have reasonably fast Ethernet connections.
> > > > Don't know how much you already did for the hardware layout. If
> > > > possible, try to avoid analog stuff, that is, ADC/DAC.
> > > You don't say why we should avoid analog stuff.
> >
> > 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.
>
> My goal is not to compete with high quality manufacturer, it is to see
> how far this takes us. Others might have other goals.

Very much my thoughts too :)

--
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.

[Gene Heskett]

On Tuesday 24 November 2009, Adrian Knoth wrote:
>On Tue, Nov 24, 2009 at 09:48:53AM +0100, Karl Hammar wrote:
>> So ich habe mal was zusammengedichtet ....
>>
>> > > The rationale in brief:
>> > > No proprietry hardware soundcard needed.
>> > > Almost all modern computers have reasonably fast Ethernet
>> > > connections.
>> >
>> > Don't know how much you already did for the hardware layout. If
>> > possible, try to avoid analog stuff, that is, ADC/DAC.
>>
>> You don't say why we should avoid analog stuff.
>
>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.
>
>> > I'm also somewhat interested in the network part, I feel IPv6 could
>> > help a lot. It supports autoconfiguration and it has decent multicast
>> > support, so it would be possible to broadcast/multicast the streams on
>> > the net (LAN). This could be useful if you want to access the stream at
>> > a mixing console for a life setup and simultaneously record it on a
>> > computer.
>>
>> At a live recording you probably have only your own gear connected to
>> the lan. In that case you can easily assign ip-adresses at will and to
>> your own taste. I don't see how IPv6 vs. IPv4 could matter at all.
>
>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]
>
>> That tells us that it should be doable. But of cause we want an open
>> protocol. Do you know the capacity limits of those systems?
>
>Approximately what you could expect from a 100MBit/s link. At least 32
>channels, rocknet even more, but they use 400MBit/s.

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.

>Cheerio

--
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"

[Florian Faber]

Atte André Jensen wrote:

> I wonder why no company took up this idea already, it seems so sleek and
> logical. (Almost) every computer has ethernet and the ethernet standard
> is (in my experience) problem free...

A lot of companies are working on this, but for anything but a simple
audio in/audio out you need technology that's not yet available to the
broad public - at least not to the usual prices. Check out the AVB
specification (IEEE 802.1).

In the broadcast/studio segment, transport over ethernet is already in
use by some manufacturers.


Flo
--
Machines can do the work, so people have time to think.
public key DA43FEF4 x-hkp://wwwkeys.eu.pgp.net

[Hans Wilmers]

Florian Faber wrote:
> Atte André Jensen wrote:
>
>
>> I wonder why no company took up this idea already, it seems so sleek and
>> logical. (Almost) every computer has ethernet and the ethernet standard
>> is (in my experience) problem free...
>>
>
> A lot of companies are working on this, but for anything but a simple
> audio in/audio out you need technology that's not yet available to the
> broad public - at least not to the usual prices. Check out the AVB
> specification (IEEE 802.1).
>
> In the broadcast/studio segment, transport over ethernet is already in
> use by some manufacturers.
>
>
> Flo
>
Yes, there is an overview over protocols here:
http://en.wikipedia.org/wiki/Audio_over_Ethernet

/ Hans

[Folderol]

Wow! A lot been said since I opened my mouth :o

First an apology!

When I started this thread I CC'd LAU hoping to just bring interested
people over. I didn't expect the cross-post deluge that followed -
Sorry. I won't do it again :(

For those in doubt the original discussion started over on LAU as a
complaint about the state of USB support on Linux.

My take is very much like Karl's in many respects.

I want to keep well clear of any propriety issues such as patents,
licenses etc. You can't get much more 'free' that real analog audio,
and Ethernet is a pretty much universal and unencumbered standard. If
all the software and hardware remains open then I think we're pretty
much covered.

Another reason for going for a nuts & bolts build is that it will be a
*fun* challenge. I certainly do not expect broadcast standard feeds from
our first attempt, but if we can produce something that is reliable and
repeatable then I'm sure those that are more experienced than myself
will be able to point us in the right direction for fine tuning both
the hardware and software, but we really need a brick in place first.

Karl and I and some others I think more or less agreed that the first
step was to produce a simple development board with just two inputs as
a starter. The unit that Karl though most promising already has 16bit
DACs on board so a complete 2 in 2 out should be realisable fairly
quickly. For this first test, I'm not at all concerned about noise
levels. I think getting a reasonably low distortion conversion without
any discontinuities is the first target.

If the triggering of fast ADCs is controlled by a reasonably accurate
Xtal standard is doesn't really matter if the computer end drifts
about a bit, the odd lost packet should be recoverable and jack really
won't care as long as it's buffers are filled and emptied within the
overall time frame.

I know very little about networking, but the Wikipedia link very
much confirms my early thoughts that there aren't
any effective standards in place.

UDP also looks the way to go. Everything is permanently listening to
everything else, but only the master controller sends out polling
messages dictating which slaves will 'speak'. To me, this keeps the
protocol as simple, fast and flexible as possible and should completely
avoid collisions. It would seem other people have come to a similar
conclusion.

As we are working FOSS, everything is open for scrutiny and later
development of the messaging system is not a great hardship. Practical
experience can dictate what *really* is good and what isn't.


A little bit of sad news.
I decided to fire up my ancient valve voltmeter, notch filters etc. and
have a look at the distortion products from a mathematically generated
1kHz sinewave spat out by my 2496 sound card, just to give some form of
reference. Unfortunately the meter has gone to that great repair shop in
the sky :(
So...
My immediate project is now to build myself a battery operated digital
AC millviltmeter with true RMS volts and dB scaling based around Analog
Devices AD636.

Parts are on order :D

--
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]

It's late, but I can't sleep, so...
Refining my protocol thoughts, which I originally posted on LAU.

There is one master, which would probably be the computer, but I can
envisage a situation where there could be more than one computer and
only one of them would be the master, the other would be a slave like
everything else.

When each slave starts it sends a simple 'hello' message, say once
every 50mS until it gets a query back. This way it doesn't matter
which order the master and slaves are started. At this stage it only
listens for a default channel which would only be sent by the master.

When the master gets a 'hello' it sends a message requesting the
following: textual name of the device
bit depths the slave can handle
sample rates
number of input channels
number of output channels
It then assigns virtual channel IDs that the slave is to use from now
on based on what else is connected etc.

Once it has this information it can tell the slave to do any of the
following:
perform general initialisation and set all defaults (panic!)
change textual name to '?????'
set bit depth -> 8, 16, 24, ? (default 16)
set sample rate -> 44.1, 48, 96, ? (default 48)
set unit as clock reference or not (default not)
enable/disable CH 'n' listen to broadcast CH 'x' (default master)
enable/disable CH'n' input (default disable)
enable/disable CH'n' output (default disable)
set CH'n' gain/output (default silence)

Audio data transmission is initiated by the master polling for each
active virtual input channel to send its data (obviously ignoring
output ones). Also bearing in mind that the master will itself be
generating and sending out processed audio data on multiple channels.

Changing name (which should ideally be stored permanently) enables you
to define a unit as say, 'front 4 mics' or 'control room monitors'. In
future the master could automatically link this name to previously
defined channel IDs.

Enabling the listening channels should work in parallel, in that a unit
will always listen to the master channel, but could also listen to any
number of other channels and route them accordingly. This gives a very
flexible multicast in that you can have all streams currently being
transmitted routed selectively directly to monitors, headphones etc.

Disabling a channel is not the same as setting it's level to silence,
as at silence it would still generate output to be fed into the network.
It would make sense to stop any meaningless data transfers.

With a switched binary volume control 7 bits would give you 127dB range
(LSB=1dB) so the 8th bit could be used to simply ground that channel.
I'm not even sure you need to go as tight as 1dB. Fine control would be
done within the DAW anyway.

If anyone can see any obvious holes in this or simplifications please
say so.

I'll be listening on all channels :)

--
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.

[Jens M Andreasen]

On Thu, 2009-11-26 at 01:24 +0000, Folderol wrote:
> It's late, but I can't sleep, so...

> set sample rate -> 44.1, 48, 96, ? (default 48)

> If anyone can see any obvious holes in this or simplifications please
> say so.


Crystals controlling inexpensive DAC'c and ADC's will be drifting. There
should be a solder-iron solution for that, but only as long as they live
in the same box.

Upsampling to 192k at the receiving end to better hide the
skipped/inserted samples might be an idea.

[Folderol]

On Thu, 26 Nov 2009 03:44:51 +0100
Jens M Andreasen <***@comhem.se> wrote:

>
> On Thu, 2009-11-26 at 01:24 +0000, Folderol wrote:
> > It's late, but I can't sleep, so...
>
> > set sample rate -> 44.1, 48, 96, ? (default 48)
>
> > If anyone can see any obvious holes in this or simplifications please
> > say so.
>
>
> Crystals controlling inexpensive DAC'c and ADC's will be drifting. There
> should be a solder-iron solution for that, but only as long as they live
> in the same box.

ADCs with built-in very fast conversions (1-2uS), externally triggered
by precision tunable oscillators, these (across different boards)
frequency locked by very slow, averaging FLLs. Phase may be skewed but
frequency should be held.

> Upsampling to 192k at the receiving end to better hide the
> skipped/inserted samples might be an idea.

Or possibly interpolation between the two either side of the missing
one.

--
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.

[Michael Chapman]

On Thursday 26 November 2009 1:24 am, Folderol wrote:

> Once it has this information it can tell the slave to do any of the
> following:
> perform general initialisation and set all defaults (panic!)
> change textual name to '?????'
> set bit depth -> 8, 16, 24, ? (default 16)

I may be wrong, but I have the impression most 'non-computer' converters are
integer.
Looking to the future floating point does have a lot of advantages (esp. for
'remote' devices).
Floating point seems to mean
32-bit bit-depth
so in the hope that we may get there, can we have 32 as well?

Michael

[f***@kokkinizita.net]

On Tue, Nov 24, 2009 at 11:26:04AM +0100, Florian Faber wrote:

> > I wonder why no company took up this idea already, it seems so sleek and
> > logical. (Almost) every computer has ethernet and the ethernet standard
> > is (in my experience) problem free...
>
> A lot of companies are working on this, but for anything but a simple
> audio in/audio out you need technology that's not yet available to the
> broad public - at least not to the usual prices. Check out the AVB
> specification (IEEE 802.1).
>
> In the broadcast/studio segment, transport over ethernet is already in
> use by some manufacturers.

In the segment of large fixed audio installations (airports,
train stations, cruise ships, etc.) things like Cobranet have
been in use for many years - the savings in wiring costs and
the gain in flexibility are enormous.

Ciao,

--
FA

Io lo dico sempre: l'Italia è troppo stretta e lunga.

[Florian Faber]

Fons!

>> In the broadcast/studio segment, transport over ethernet is already in
>> use by some manufacturers.
> In the segment of large fixed audio installations (airports,
> train stations, cruise ships, etc.) things like Cobranet have
> been in use for many years - the savings in wiring costs and
> the gain in flexibility are enormous.

And there will be additional savings with the raise of open protocols
for all kinds of media. We have used proprietary interfaces long enough.


Flo
--
Machines can do the work, so people have time to think.
public key DA43FEF4 x-hkp://wwwkeys.eu.pgp.net

[Ray Rashif]

Hmm..this is definitely interesting. When specs and schematics are up, if
the hardware is within my budget, I'll most certainly be testing the idea.

[Florian Faber]

Kevin Cosgrove wrote:

>> Yes, there is an overview over protocols here:
>> http://en.wikipedia.org/wiki/Audio_over_Ethernet
> Seems like the latter reference is quite far ahead of the IEEE
> thoughts.

And how many of them are open standards?


Flo
--
Machines can do the work, so people have time to think.
public key DA43FEF4 x-hkp://wwwkeys.eu.pgp.net

[a***@poczta.fm]

[Jack Hildwine]

A similar circuit using the AD636 coupled with the ICL7106 A/D and LCD
driver is detailed in the July 2009 audioXpress magazine.

http://www.audioxpress.com

There is, however, no PCB or parts kit available and I'm not certain
that the artwork for the PCB that's printed is to scale although it
looks like it is.

Jack

-----Original Message-----
From: linux-audio-dev-***@lists.linuxaudio.org
[mailto:linux-audio-dev-***@lists.linuxaudio.org] On Behalf Of
Folderol
Sent: Thursday, December 03, 2009 3:30 PM
To: linux-audio-***@lists.linuxaudio.org
Subject: [LAD] Milivoltmeter - Was FOSS Ethernet Soundcard

On Wed, 2 Dec 2009 17:19:30 +0000
Folderol <***@ukfsn.org> wrote:

> On Tue, 1 Dec 2009 21:46:32 +0100 (CET)
> ***@aspodata.se (Karl Hammar) wrote:
>
> > Folderol:
> > ...
> > > My new millivoltmeter/dB meter is nearly finished - All I need now
is
> > > precision resistors 9M, 900k, 90k :?
> > ...
> >
> > Can you publicise it so I can build me one also?
> >
> > Regards,
> > /Karl
>
> 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.

As promised, PDF attached.
I haven't had time to make out any explanatory notes, but I think it's
pretty straight forward anyway

0dB is variable so it can be set to whatever is convenient, hence
temperature drift from using an ordinary diode as a reference is not
important.

--
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.