20 Oct
2011
20 Oct
'11
9:54 p.m.
Hi, list
I'm interested in getting feedback for a project, namely building an
audio interface, with the goal of creating freely available schematics
and code required. Hence, an Open Sound Interface.
Once I've heard from all those interested, we may want to migrate the
discussion to another development oriented list such as the
linux-audio-dev list to work out nitty-gritty technical details. For
now, it's enough just to gauge interest and deal with planning issues.
The concept is to create a modular and scalable system that allows
users to create a sound interface with an arbitrary number of
input/output channels.
Goals of the system:
1. low latency
2. isolate design considerations
3. abstraction of data transport types
4. flexibility of adc/dac/preamp combinations
5. no unnecessary features--keep it lean; niche features can be added
in by those interested
My idea for how to do it, and components/tasks to design:
1. Modules for dac and adc with on-board identifiers (mixed-signal design)
2. A FPGA-based programmable system board with connectors for
respective modules (high-frequency circuit design)
3. FPGA code for buffers, clocks, and device discovery (VHDL/Verilog
programming)
4. Data transport modules (FPGA code plus hardware design), could be
USB, FW, ETH, PCI, wireless, etc...
5. Kernel modules for each type of transport (software design)
6. Power supplies (not especially difficult, but tough to find
off-the-shelf components to meet specs)
What I'm doing:
studying VHDL coding and preparing to test I2C/SPI dacs on a Digilent
Basys-2 board with breadboards (maybe over a few months)
studying high frequency electronics design
This sort of problem would take a good team to do well. There's room
for many levels of software/hardware expertise, especially those who
understand linux audio kernel modules (design for many parts of the
system depend on capabilities to design for).
It may be a chore, but some kind of organization and design documents
will be needed. All the components are inter-related: it takes a
combination of top-down (whole system) and bottom-up (per module)
considerations to build a complete design.
Any feedback, insights, practical considerations, and reasonable
expectations for taking a complex project like this to completion
would be welcome.
Thanks,
Chuck
21 Oct
21 Oct
4:47 p.m.
I'm going to go ahead and say that, while I am not capable of
contributing code or electronics design, I would love to see this kind
of thing come to fruition. It's a wonderful concept that I think
many, including myself, would find very, very useful. As well, I
think, from my experience with LAD and the community, we have
everything we need to realize this.
I could certainly contribute time to documentation and such.
On 10/20/11, Charles Henry <czhenry(a)gmail.com> wrote:
Hi, list
I'm interested in getting feedback for a project, namely building an
audio interface, with the goal of creating freely available schematics
and code required. Hence, an Open Sound Interface.
Once I've heard from all those interested, we may want to migrate the
discussion to another development oriented list such as the
linux-audio-dev list to work out nitty-gritty technical details. For
now, it's enough just to gauge interest and deal with planning issues.
The concept is to create a modular and scalable system that allows
users to create a sound interface with an arbitrary number of
input/output channels.
Goals of the system:
1. low latency
2. isolate design considerations
3. abstraction of data transport types
4. flexibility of adc/dac/preamp combinations
5. no unnecessary features--keep it lean; niche features can be added
in by those interested
My idea for how to do it, and components/tasks to design:
1. Modules for dac and adc with on-board identifiers (mixed-signal design)
2. A FPGA-based programmable system board with connectors for
respective modules (high-frequency circuit design)
3. FPGA code for buffers, clocks, and device discovery (VHDL/Verilog
programming)
4. Data transport modules (FPGA code plus hardware design), could be
USB, FW, ETH, PCI, wireless, etc...
5. Kernel modules for each type of transport (software design)
6. Power supplies (not especially difficult, but tough to find
off-the-shelf components to meet specs)
What I'm doing:
studying VHDL coding and preparing to test I2C/SPI dacs on a Digilent
Basys-2 board with breadboards (maybe over a few months)
studying high frequency electronics design
This sort of problem would take a good team to do well. There's room
for many levels of software/hardware expertise, especially those who
understand linux audio kernel modules (design for many parts of the
system depend on capabilities to design for).
It may be a chore, but some kind of organization and design documents
will be needed. All the components are inter-related: it takes a
combination of top-down (whole system) and bottom-up (per module)
considerations to build a complete design.
Any feedback, insights, practical considerations, and reasonable
expectations for taking a complex project like this to completion
would be welcome.
Thanks,
Chuck
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
5:25 p.m.
Hi Egor
Thanks for your interest. It's certainly a very big idea--none of the
individual parts are so difficult to design, but there's a lot of
them.
I'd appreciate your offer to work on documentation. The best thing we
can do now is design, work with concepts, and little-by-little start
building the pieces.
In your opinion, what kind of tools should we use to organize such a
project? like websites, wiki, mailing list, repository, etc... ?
Chuck
On Fri, Oct 21, 2011 at 9:47 AM, Egor Sanin <egor.sanin(a)gmail.com> wrote:
I'm going to go ahead and say that, while I am not
capable of
contributing code or electronics design, I would love to see this kind
of thing come to fruition. It's a wonderful concept that I think
many, including myself, would find very, very useful. As well, I
think, from my experience with LAD and the community, we have
everything we need to realize this.
I could certainly contribute time to documentation and such.
25 Oct
25 Oct
8:46 p.m.
On Fri, Oct 21, 2011 at 7:25 PM, Charles Henry <czhenry(a)gmail.com> wrote:
In your opinion, what kind of tools should we use to
organize such a
project? like websites, wiki, mailing list, repository, etc... ?
I'm not Egor :), but you could just use Google Code and a Google
group. On Google Code you get an abitrary repository (SVN, Git,
Mercurial), wiki and issue tracker. And a google group os pretty much
a mailing list. Of course you can always go for SourceForge and its
own set of tools. Or Github/Gitorious (both provide Git repo and wiki)
and something for ML.
Alexandre Prokoudine
http://libregraphicsworld.org
9:14 p.m.
On 10/25/11, Alexandre Prokoudine <alexandre.prokoudine(a)gmail.com> wrote:
On Fri, Oct 21, 2011 at 7:25 PM, Charles Henry
<czhenry(a)gmail.com> wrote:
My apologies for not responding earlier!
I personally am very much against Google for this sort of thing. I
feel that in the event their tools are used for organization, the
ignorant mass will automatically assume that Google is doing linux a
favour and somehow contributing to this project.
As for something constructive, I'm afraid I have close to no
experience with this kind of organization. I think the linuxaudio.org
folks could bring their insight into this.
In your opinion, what kind of tools should we use
to organize such a
project? like websites, wiki, mailing list, repository, etc... ?
I'm not Egor :), but you could just use Google Code and a Google
group.
9:21 p.m.
On Tue, Oct 25, 2011 at 2:14 PM, Egor Sanin <egor.sanin(a)gmail.com> wrote:
On 10/25/11, Alexandre Prokoudine
<alexandre.prokoudine(a)gmail.com> wrote:
A main item we want to have is support for binary files--I think this
is handled well with git, right?
The code itself (VHDL or Verilog) is hardware independent, but a
compiled file is specific for a particular FPGA device. Users won't
ever want to have to build from source--just flash binaries.
Chuck
On Fri, Oct 21, 2011 at 7:25 PM, Charles Henry
<czhenry(a)gmail.com> wrote:
My apologies for not responding earlier!
I personally am very much against Google for this sort of thing. I
feel that in the event their tools are used for organization, the
ignorant mass will automatically assume that Google is doing linux a
favour and somehow contributing to this project. In your opinion, what kind of tools should we use
to organize such a
project? like websites, wiki, mailing list, repository, etc... ?
I'm not Egor :), but you could just use Google Code and a Google
group. 
26 Oct
26 Oct
8:04 p.m.
Hello Charles Henry,
I am Electronic Engineer and a little bit more...
Am 2011-10-25 14:21:12, hacktest Du folgendes herunter:
The code itself (VHDL or Verilog) is hardware
independent, but a
compiled file is specific for a particular FPGA device. Users won't
ever want to have to build from source--just flash binaries.
I do not know VHDL/Verilogand have never programmed a FPGA, but do you
do this under Linux or do you use propriatary tools of the FPGA
manufacturers?
Chuck
Thanks, Greetings and nice Day/Evening
Michelle Konzack
--
##################### Debian GNU/Linux Consultant ######################
Development of Intranet and Embedded Systems with Debian GNU/Linux
Internet Service Provider, Cloud Computing
<http://www.itsystems.tamay-dogan.net/>
itsystems@tdnet Jabber linux4michelle(a)jabber.ccc.de
Owner Michelle Konzack
Gewerbe Strasse 3 Tel office: +49-176-86004575
77694 Kehl Tel mobil: +49-177-9351947
Germany Tel mobil: +33-6-61925193 (France)
USt-ID: DE 278 049 239
Linux-User #280138 with the Linux Counter, http://counter.li.org/
8:30 p.m.
On Wed, Oct 26, 2011 at 1:04 PM, Michelle Konzack
<linux4michelle(a)tamay-dogan.net> wrote:
Hello Charles Henry,
I am Electronic Engineer and a little bit more...
Am 2011-10-25 14:21:12, hacktest Du folgendes herunter:
As far as I know, there's no open source tools to compile FPGA code.
It's always device specific. Starting with VHDL/Verilog source
(device independent) and an I/O pin-mapping file (per device), you
generate a net-list file and then it has to be mapped/routed for the
specifc device. Any advice on tools to use or study is most welcome.
It seems to be a lengthy process that takes some skill. So developing
the binaries to be flashed is a bit outside most users' ability--but
flashing from JTAG headers can be accomplished by a few free tools.
The code itself (VHDL or Verilog) is hardware
independent, but a
compiled file is specific for a particular FPGA device. Users won't
ever want to have to build from source--just flash binaries.
I do not know VHDL/Verilogand have never programmed a FPGA, but do you
do this under Linux or do you use propriatary tools of the FPGA
manufacturers?
25 Oct
25 Oct
9:23 p.m.
On Tue, Oct 25, 2011 at 11:14 PM, Egor Sanin wrote:
I personally am very much against Google for this sort
of thing. I
feel that in the event their tools are used for organization, the
ignorant mass will automatically assume that Google is doing linux a
favour and somehow contributing to this project.
I don't understand why anyone would think so (never heard of Google
being wronlgy atttributed for projects they simply host), but then
again I'm not exactly interested in further duscussion on this anyway
as I'd love to see politics flavoured discussions just burn in hell :)
As for something constructive, I'm afraid I have
close to no
experience with this kind of organization. I think the linuxaudio.org
folks could bring their insight into this.
Well, I did suggest other options :)
For my own projects I use Gitorious, so I don't see why you coulln't
use an arbitrary code hosting with a wiki (Github, Gitorious,
Bitbucket, SourceForge etc) and ask linuxaudio folks to setup a new
mialing list.
Alexandre Prokoudine
http://libregraphicsworld.org
9:59 p.m.
On 10/25/11, Alexandre Prokoudine <alexandre.prokoudine(a)gmail.com> wrote:
I don't understand why anyone would think so
(never heard of Google
being wronlgy atttributed for projects they simply host), but then
I'm thinking
along the lines of Mr. So and So saying "Huh? Linux?
That's that Android thing, right?"
again I'm not exactly interested in further
duscussion on this anyway
as I'd love to see politics flavoured discussions just burn in hell :)
But I
agree with you here! Sorry for my burst of choler.
Well, I did suggest other options :)
I think
those are great!
26 Oct
26 Oct
8 p.m.
Hello Alexandre Prokoudine,
Am 2011-10-25 22:46:17, hacktest Du folgendes herunter:
I'm not Egor :), but you could just use Google
Code and a Google
group. On Google Code you get an abitrary repository (SVN, Git,
"Google Group" is a very bad idea, because if you have no GMail account
you can not use it.
Mercurial), wiki and issue tracker. And a google group
os pretty much
a mailing list.
???
Of course you can always go for SourceForge and its
own set of tools. Or Github/Gitorious (both provide Git repo and wiki)
and something for ML.
Would be some times better
Thanks, Greetings and nice Day/Evening
Michelle Konzack
--
##################### Debian GNU/Linux Consultant ######################
Development of Intranet and Embedded Systems with Debian GNU/Linux
Internet Service Provider, Cloud Computing
<http://www.itsystems.tamay-dogan.net/>
itsystems@tdnet Jabber linux4michelle(a)jabber.ccc.de
Owner Michelle Konzack
Gewerbe Strasse 3 Tel office: +49-176-86004575
77694 Kehl Tel mobil: +49-177-9351947
Germany Tel mobil: +33-6-61925193 (France)
USt-ID: DE 278 049 239
Linux-User #280138 with the Linux Counter, http://counter.li.org/
25 Oct
25 Oct
8:21 p.m.
On 10/20/2011 10:54 PM, Charles Henry wrote:
Hi, list
I'm interested in getting feedback for a project, namely building an
audio interface, with the goal of creating freely available schematics
and code required. Hence, an Open Sound Interface.
Once I've heard from all those interested, we may want to migrate the
discussion to another development oriented list such as the
linux-audio-dev list to work out nitty-gritty technical details. For
now, it's enough just to gauge interest and deal with planning issues.
The concept is to create a modular and scalable system that allows
users to create a sound interface with an arbitrary number of
input/output channels.
Goals of the system:
1. low latency
2. isolate design considerations
3. abstraction of data transport types
4. flexibility of adc/dac/preamp combinations
5. no unnecessary features--keep it lean; niche features can be added
in by those interested
My idea for how to do it, and components/tasks to design:
1. Modules for dac and adc with on-board identifiers (mixed-signal design)
2. A FPGA-based programmable system board with connectors for
respective modules (high-frequency circuit design)
3. FPGA code for buffers, clocks, and device discovery (VHDL/Verilog
programming)
4. Data transport modules (FPGA code plus hardware design), could be
USB, FW, ETH, PCI, wireless, etc...
5. Kernel modules for each type of transport (software design)
6. Power supplies (not especially difficult, but tough to find
off-the-shelf components to meet specs)
What I'm doing:
studying VHDL coding and preparing to test I2C/SPI dacs on a Digilent
Basys-2 board with breadboards (maybe over a few months)
studying high frequency electronics design
This sort of problem would take a good team to do well. There's room
for many levels of software/hardware expertise, especially those who
understand linux audio kernel modules (design for many parts of the
system depend on capabilities to design for).
It may be a chore, but some kind of organization and design documents
will be needed. All the components are inter-related: it takes a
combination of top-down (whole system) and bottom-up (per module)
considerations to build a complete design.
Any feedback, insights, practical considerations, and reasonable
expectations for taking a complex project like this to completion
would be welcome.
Thanks,
Chuck
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
Awesome, I've been thinking about this myself too, There actually is a
DA interface project that I found some months ago.. maby one could use
that as a base ! I might be able to contribute with some electronics,
mostly testing.. I'm more or less a beginner atm but I know how all
basic components affect the signal... But yes, this have to be done,
It's not like there'll be better audio interface linux support in the
future...
9:13 p.m.
On Tue, Oct 25, 2011 at 1:17 PM, alexander <axeldenstore(a)gmail.com> wrote:
Awesome, I've been thinking about this myself too,
There actually is a DA
interface project that I found some months ago.. maby one could use that as
a base ! I might be able to contribute with some electronics, mostly
testing.. I'm more or less a beginner atm but I know how all basic
components affect the signal... But yes, this have to be done, It's not like
there'll be better audio interface linux support in the future...
I'm glad to hear you had the same idea. We might be crazy, but I
think it's worth a try :D
And there's also plenty of work designing high-speed data acquisition
hardware (into the millions of samples per second) with the platform
(FPGAs + ASIC) I'm proposing. What DA project have you seen lately?
Chuck
11:52 p.m.
DA interface project that I found some months ago..
vaguely rings a bell. more recently ive seen SDR-Widget, as radio is quite demanding of
ADC noise-floor quietness, flatness - eg most Intel HDA cards are not really capable of
192khz sampling with a fixed ~22KHz brickwall LPF (prevent aliasing at low samplerates)
which isnt switched to a different LPF at higher rates (cost reasons presumably) and even
"good" cards like emu 0202 could be improved upon..
http://sdr-widget.googlecode.com/files/Draft4_Sound_card_noise_floor_compar…
26 Oct
26 Oct
3:52 p.m.
On Tue, Oct 25, 2011 at 4:52 PM, pod <_(a)whats-your.name> wrote:
This looks good to study--that analog board has great noise characteristics.
And the IC uses I2S, another standard bus that could be good to use.
Overall, what I'm most impressed by is their timeline--completed the
device plus linux drivers in about 1 year.
DA interface
project that I found some months ago..
vaguely rings a bell. more recently ive seen SDR-Widget, as radio is quite demanding of
ADC noise-floor quietness, flatness - eg most Intel HDA cards are not really capable of
192khz sampling with a fixed ~22KHz brickwall LPF (prevent aliasing at low samplerates)
which isnt switched to a different LPF at higher rates (cost reasons presumably) and even
"good" cards like emu 0202 could be improved upon..
http://sdr-widget.googlecode.com/files/Draft4_Sound_card_noise_floor_compar…
6:01 p.m.
On Wed, Oct 26, 2011 at 08:52:14AM -0500, Charles Henry wrote:
This looks good to study--that analog board has great noise characteristics.
Yes. To get the full story you should also zoom in on the 0-500Hz range.
Noise density will rise in that range, and there will be mains frequency
harmonics leaking in.
Provided the noise density is flat in the audio range, the unweighted
S/N for 20 kHz bandwidth would be -(No + 43) dB, i.e. 114.8 dB for the
SDR Widget Lite Alpha2, which is quite good. For an A-weighted value
add 2.2 dB.
The best way to measure the actual noise level would be jnoisemeter.
Ciao,
--
FA
25 Oct
25 Oct
9:42 p.m.
On Thu, 20 Oct 2011 14:54:46 -0500
Charles Henry <czhenry(a)gmail.com> wrote:
Hi, list
I'm interested in getting feedback for a project, namely building an
audio interface, with the goal of creating freely available schematics
and code required. Hence, an Open Sound Interface.
Hi, I find this idea remarkable. I'm not able to contribute on the
technical parts, but I just wanted to signal you something I found out
some time ago:
http://www.ohwr.org/projects/cernohl/wiki/CernOhlProjects
basically, from what I understand, at CERN in Switzerland they
developed a license for open source hardware ("The CERN–OHL is to
hardware what the General Public Licence (GPL) is to software"), and
they're working on several pieces of hardware under this license. If
you go in the "Projects" section, you can see there are some ADCs and
DACs, so maybe you can find some useful stuff for your project :)
cheers and good luck,
renato
9:59 p.m.
On Tue, Oct 25, 2011 at 2:41 PM, Renato <rennabh(a)gmail.com> wrote:
On Thu, 20 Oct 2011 14:54:46 -0500
Charles Henry <czhenry(a)gmail.com> wrote:
This is also terrific information! There's some great HDL/FPGA info
under projects, which covers some of the hardware interfaces that I've
been considering.
Also, some hardware DAQ projects (stuff in the Msamples/sec range,
which is higher spec than we're interested in for right now). Thanks
for the info!
Hi, list
I'm interested in getting feedback for a project, namely building an
audio interface, with the goal of creating freely available schematics
and code required. Hence, an Open Sound Interface.
Hi, I find this idea remarkable. I'm not able to contribute on the
technical parts, but I just wanted to signal you something I found out
some time ago:
http://www.ohwr.org/projects/cernohl/wiki/CernOhlProjects
basically, from what I understand, at CERN in Switzerland they
developed a license for open source hardware ("The CERN–OHL is to
hardware what the General Public Licence (GPL) is to software"), and
they're working on several pieces of hardware under this license. If
you go in the "Projects" section, you can see there are some ADCs and
DACs, so maybe you can find some useful stuff for your project :)
cheers and good luck,
renato
10:25 p.m.
On Tue, 25 Oct 2011 14:59:13 -0500
Charles Henry <czhenry(a)gmail.com> wrote:
This is also terrific information! There's some
great HDL/FPGA info
under projects, which covers some of the hardware interfaces that I've
been considering.
Also, some hardware DAQ projects (stuff in the Msamples/sec range,
which is higher spec than we're interested in for right now). Thanks
for the info!
glad to hear it helps :)
renato
26 Oct
26 Oct
10:15 a.m.
Chuck,
On 20/10/2011 21:54, Charles Henry wrote:
Hi, list
I'm interested in getting feedback for a project, namely building an
audio interface, with the goal of creating freely available schematics
and code required. Hence, an Open Sound Interface.
This sounds very interesting. I wouldn't be able to contribute on the
technical side at this stage I guess. But thumbs up from a potential
user and maybe later tester, documenter, etc.!
You already mentioned USB and FW which IMHO is good as this should also
target the big 'proprietary gap' issuee in 'mobile' interfaces (i.e.
Linux users are still forced to dig into devices which are supported in
ffado etc.)
Recently on the list I shared a probably more ambitious idea, which is
integrating an interface like this and making and Open Daw Laptop (so tu
say), similar to Indamixx but with fairly hi-q audio interface.
Unfortunately I don't have the hardware knowledge to express it as
clearly as you did, but maybe in a later stage the idea could be
resurrected :)
Lorenzo.
Once I've heard from all those interested, we may want to migrate the
discussion to another development oriented list such as the
linux-audio-dev list to work out nitty-gritty technical details. For
now, it's enough just to gauge interest and deal with planning issues.
The concept is to create a modular and scalable system that allows
users to create a sound interface with an arbitrary number of
input/output channels.
Goals of the system:
1. low latency
2. isolate design considerations
3. abstraction of data transport types
4. flexibility of adc/dac/preamp combinations
5. no unnecessary features--keep it lean; niche features can be added
in by those interested
My idea for how to do it, and components/tasks to design:
1. Modules for dac and adc with on-board identifiers (mixed-signal design)
2. A FPGA-based programmable system board with connectors for
respective modules (high-frequency circuit design)
3. FPGA code for buffers, clocks, and device discovery (VHDL/Verilog
programming)
4. Data transport modules (FPGA code plus hardware design), could be
USB, FW, ETH, PCI, wireless, etc...
5. Kernel modules for each type of transport (software design)
6. Power supplies (not especially difficult, but tough to find
off-the-shelf components to meet specs)
What I'm doing:
studying VHDL coding and preparing to test I2C/SPI dacs on a Digilent
Basys-2 board with breadboards (maybe over a few months)
studying high frequency electronics design
This sort of problem would take a good team to do well. There's room
for many levels of software/hardware expertise, especially those who
understand linux audio kernel modules (design for many parts of the
system depend on capabilities to design for).
It may be a chore, but some kind of organization and design documents
will be needed. All the components are inter-related: it takes a
combination of top-down (whole system) and bottom-up (per module)
considerations to build a complete design.
Any feedback, insights, practical considerations, and reasonable
expectations for taking a complex project like this to completion
would be welcome.
Thanks,
Chuck
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
30 Oct
30 Oct
2:56 p.m.
2011/10/20 Charles Henry <czhenry(a)gmail.com>om>:
... feedback for a project, namely building an
audio interface, with the goal of creating freely available schematics
and code ...
The concept is to create a modular and scalable system that allows
users to create a sound interface with an arbitrary number of
input/output channels.
Great project !
Maybe try some fund-raising ?
Now, say thanks to those xmos people, they have a
whole reference design ready, inclusive buyable prototype:
http://www.xmos.com/products/development-kits/usbaudio2mc
Note: This is based on xmos technology, XC - a C like language, that
allows implicit parallel programming.
I heard USB-Audio-Class-2.0 is already supported by ALSA (driver architecture),
thus this device might work OOTB or with very little effort on linux.
In the following, some of my ideas:
You could take it as base,
- modularize it further
- or add some missing components,
- make IOs balanced,
- add ADAT
- add AES3, (AES/EBU)
- add AES10 (MADI)
- add AVB
- support MIDI IO
- Allow the synchronization of two or more cards, to allow more than 6
IN channels.
- Make most of it optional and modular.
- Make 1 (extensible) low-cost + 1 (all-incl.) high-end design
Since most of the modules exist, work is to connect and integrate all of it,
and the design of a beautiful case and package ;)
I would make most of the design digital, with the exception of pre-ADC
(analog limiter, balancer) and post-DAC (amplifier, balancer) stages.
You would end with about these modular stages:
- analog inputs ADC_01 ... ADC_XX
- ADCs would deliver I2S streams, send to a mixer (fpga ? or xmos uC)
, or directly to output modules.
- digital IO SPDIF
- digital IO ADAT
- digital IO AES3
- digital IO AVB
- digital IO USB 2.0
- digital IO IEEE 1394 (maybe)
- digital word clock (75Ω BNC)
- analog outputs DAC_01 .. DAC_XX, would receive digital I2S streams
- controler , routing-, configuration- and switching module
Digital INs would be routed to the mixer stage.
Digital OUTs, could optionally be routed back to the mixer stage,
maybe with a feedback-loop detection, to prevent damage of ear and device.
--
E.R.
2 Nov
2 Nov
2:48 a.m.
On Sun, Oct 30, 2011 at 8:56 AM, Emanuel Rumpf <xbran(a)web.de> wrote:
2011/10/20 Charles Henry <czhenry(a)gmail.com>om>:
Good point. That's a consideration that needs to be up front.
... feedback for a project, namely building an
audio interface, with the goal of creating freely available schematics
and code ...
The concept is to create a modular and scalable system that allows
users to create a sound interface with an arbitrary number of
input/output channels.
Great project !
Maybe try some fund-raising ? Now, say thanks to those xmos people, they have a
whole reference design ready, inclusive buyable prototype:
http://www.xmos.com/products/development-kits/usbaudio2mc
Note: This is based on xmos technology, XC - a C like language, that
allows implicit parallel programming.
I heard USB-Audio-Class-2.0 is already supported by ALSA (driver architecture),
thus this device might work OOTB or with very little effort on linux.
I am floored. This leaves me about speechless. It's possibly a new
direction to go--the processors themselves are about as expensive as
FPGA chips.
In the following, some of my ideas:
You could take it as base,
- modularize it further
- or add some missing components,
- make IOs balanced,
- add ADAT
- add AES3, (AES/EBU)
- add AES10 (MADI)
- add AVB
- support MIDI IO
- Allow the synchronization of two or more cards, to allow more than 6
IN channels.
That's clearly just for the development board--I think their
processors can handle more channels, but the $350 development board
will support up to 6 channels. It would be better to develop some
board designs around the chips, and see how the cost comes out.
- Make most of it optional and modular.
- Make 1 (extensible) low-cost + 1 (all-incl.) high-end design
Yes, I tend to agree. There's several different processors in their
product line, and it's a good development platform to look at tiered
approaches with different goals.
Since most of the modules exist, work is to connect
and integrate all of it,
and the design of a beautiful case and package ;)
I would make most of the design digital, with the exception of pre-ADC
(analog limiter, balancer) and post-DAC (amplifier, balancer) stages.
You would end with about these modular stages:
- analog inputs ADC_01 ... ADC_XX
- ADCs would deliver I2S streams, send to a mixer (fpga ? or xmos uC)
, or directly to output modules.
- digital IO SPDIF
- digital IO ADAT
- digital IO AES3
- digital IO AVB
- digital IO USB 2.0
- digital IO IEEE 1394 (maybe)
- digital word clock (75Ω BNC)
- analog outputs DAC_01 .. DAC_XX, would receive digital I2S streams
- controler , routing-, configuration- and switching module
Digital INs would be routed to the mixer stage.
Digital OUTs, could optionally be routed back to the mixer stage,
maybe with a feedback-loop detection, to prevent damage of ear and device.
--
E.R.
Thanks for your feedback, Emanuel. It's sort of a game-changer to me.
Clearly, there's no point in starting a project that would duplicate
an existing solution. I appreciate new information like this.
I'll have to think this over for quite a while to see which way I'd
want to go--whether there's a worthy project goal in an FPGA based
design that cannot be more easily (or more cheaply) accomplished.
4 Nov
4 Nov
10:32 p.m.
2011/11/2 Charles Henry <czhenry(a)gmail.com>om>:
I see.
That's clearly just for the development board--I think their
processors can handle more channels,
But a single USB 2.0 Port won't handle
much more in duplex mode, IIRC
but the $350 development board
will support up to 6 channels. It would be better to develop some
board designs around the chips, and see how the cost comes out.
Maybe.
Depending on what the base-module would require,
unit price could drop or increase.
- Make most of
it optional and modular.
- Make 1 (extensible) low-cost + 1 (all-incl.) high-end design
Yes, I tend to agree. There's several different processors in their
product line, and it's a good development platform to look at tiered
approaches with different goals.
Thanks for your feedback, Emanuel. It's sort of a game-changer to me.
Clearly, there's no point in starting a project that would duplicate
an existing solution. I appreciate new information like this.
I'll have to think this over for quite a while to see which way I'd
want to go--whether there's a worthy project goal in an FPGA based
design that cannot be more easily (or more cheaply) accomplished.
FPGAs can process much data in little time concurrently,
but as we see, alternatives open up.
Anyway, if you came up with anything new, let us know.
Kind regards,
Emanuel
--
E.R.
4772
days inactive
4787
days old
linux-audio-user@lists.linuxaudio.org
22 comments
10 participants
participants (10)
-
alexander -
Alexandre Prokoudine -
Charles Henry -
Egor Sanin -
Emanuel Rumpf -
Fons Adriaensen -
Lorenzo Sutton -
Michelle Konzack -
pod -
Renato