21 Jan
2010
21 Jan
'10
2:19 p.m.
I bought a computer online, and didn't realize that it had no
PCI slots. If I keep this computer, I lose my beloved
Echo Mia Midi. I need stereo analog and RCA S/PDIF IO,
and midi would be nice but not essential.
So, what Linux Friendly PCIE, USB, or Firewire (PCIE
first choice) interface is out there with those features
for say < $200?
Thanks,
Tobiah
21 Jan
21 Jan
2:25 p.m.
On Thu, Jan 21, 2010 at 1:21 PM, <toby(a)tobiah.org> wrote:
I bought a computer online, and didn't realize
that it had no
PCI slots. If I keep this computer, I lose my beloved
Echo Mia Midi. I need stereo analog and RCA S/PDIF IO,
and midi would be nice but not essential.
So, what Linux Friendly PCIE, USB, or Firewire (PCIE
first choice) interface is out there with those features
for say < $200?
If you like Echo stuff (which I do also), there's the AudioFire2:
http://www.echoaudio.com/Products/FireWire/AudioFire2/index.php
http://www.zzounds.com/item--ECHAUDIOFIRE2
http://ffado.org/?q=node/68
Disclaimer: Never used one, so I don't know how it performs or how
easy it is to set up.
-sean
Thanks,
Tobiah
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
3:05 p.m.
Hi,
Sean said:
Disclaimer: Never used one, so I don't know how
it performs or how
easy it is to set up.
I'm using one right now... :-) Theyre good, I've had some little trouble
getting ffado to work back in the day,
but now Ubuntu Studio, Pure:Dyne, AVLinux etc all get it right first time.
Do yourself a favour, and dont upgrade the Echo Audiofire's to version 5.*
of firmware though...
I've noticed a decreased preformance since. Kinda hard to "backwards" flash
them too... They do still work
for me though.
As Sean said, I like Echo stuff too..
Good luck, -Harry
11:04 a.m.
Hi,
I've noticed a decreased preformance since.
What kind of performance?
JACK gets the "broken pipe" syndrome quite a lot, ie It never runs longer
than like 5 minutes,
and when it is (still) working, latencies need to be higher to avoid Xruns.
The AudioFire 2 used to playback a sterio using vlc player at 2millis, while
with firmware 5.5 it needs around 5ms.
An AudioFire 12 (12 channel), plays back on all 12 channels at 2 millis,
which still has the 4.8 firmware on it,
and it's recorded 8+ tracks for 1hr 45 mins no Xrun no broken pipe.
That's my experience. This
thread<http://ubuntuforums.org/showthread.php?t=1382500>describes some
peoples experience with ubuntu and an AudioFire 12,
and downgrading the firmware.
Hope that helps! -Harry
21 Jan
21 Jan
4:35 p.m.
On Thu, Jan 21, 2010 at 6:21 PM, <toby(a)tobiah.org> wrote:
I bought a computer online, and didn't realize
that it had no
PCI slots. If I keep this computer, I lose my beloved
Echo Mia Midi.
How about a PCIe to PCI converter? They do exist, though they don't
seem all that widespread and they obviously depend on your PC form
factor and restrict the size of card you can use -- never actually
tried one myself.
The Mia MIDI was a terrific card by all accounts and I know it worked
very well with Linux. A pity to lose it.
Chris
6:01 p.m.
On Thu, Jan 21, 2010 at 10:21 AM, <toby(a)tobiah.org> wrote:
I bought a computer online, and didn't realize
that it had no
PCI slots. If I keep this computer, I lose my beloved
Echo Mia Midi. I need stereo analog and RCA S/PDIF IO,
and midi would be nice but not essential.
So, what Linux Friendly PCIE, USB, or Firewire (PCIE
first choice) interface is out there with those features
for say < $200?
Thanks,
Tobiah
Almost had the same problem. Turned out on the Intel MB I got for $5
extra I got 3 PCI slots. It's a no brainer IF you notice. I feel bad
that you didn't.
- Mark
22 Jan
22 Jan
4:13 a.m.
toby(a)tobiah.org wrote:
I need stereo analog and RCA S/PDIF IO,
and midi would be nice but not essential.
So, what Linux Friendly PCIE, USB, or Firewire (PCIE
first choice) interface is out there with those features
for say < $200?
The only PCI-E card that fits your requirements is the Asus Xonar D2X;
it has been supported since kernel 2.6.25. While internal cards tend
to be cheaper than external devices, this model makes you pay for tons
of gaming effects in the Windows driver and casemodding blinkenlights
(which don't even blink).
The E-mu 0404 USB got support for its vendor-specific controls in the
latest development version of ALSA.
Firewire devices are currently supported only by FFADO (i.e., only with
Jack); I'm writing an ALSA driver for Echo devices right now, based on
my AudioFire2.
A quick Google search tells me that each of these devices can be had for
just $199. :-)
HTH
Clemens
8:32 a.m.
On Fri, Jan 22, 2010 at 3:13 AM, Clemens Ladisch <clemens(a)ladisch.de> wrote:
Firewire devices are currently supported only by FFADO
(i.e., only with
Jack); I'm writing an ALSA driver for Echo devices right now, based on
my AudioFire2.
uh-oh. no chance we could convince you to instead help Pieter move the
streaming part of FFADO into the kernel so that it can be used by
ALSA? Apparently the core part of this has already been done.
--p
9:53 a.m.
Paul Davis wrote:
On Fri, Jan 22, 2010 at 3:13 AM, Clemens Ladisch
<clemens(a)ladisch.de> wrote:
No chance, because I'm alreading doing this; having a generic driver for
streaming is the final goal.
Best regards,
Clemens
Firewire devices are currently supported only by
FFADO (i.e., only with
Jack); I'm writing an ALSA driver for Echo devices right now, based on
my AudioFire2.
uh-oh. no chance we could convince you to instead help Pieter move the
streaming part of FFADO into the kernel so that it can be used by
ALSA? 
23 Jan
23 Jan
6:05 p.m.
Paul Davis wrote:
On Fri, Jan 22, 2010 at 3:13 AM, Clemens Ladisch
<clemens(a)ladisch.de> wrote:
Don't worry, we have already been communicating on this. I think its not
a bad idea to take things one step at a time. The FFADO codebase is not
really an example of elegance. It bears several signs of a learning
process, is (therefore) massively over-engineered, and is certainly not
suitable for kernel space (e.g. is C++, uses floats).
Furthermore the new firewire kernel stack presents an API that is much
better suited for bi-directional low-latency streaming. The current
FFADO streaming engine tries to work around the limitations of the old
stack, but as a result its architecture is not suited for the new
stack's API.
So a "move" of the streaming part of FFADO degenerates into a re-write
anyway. And rewriting just what is needed to discover the audiofire is a
better idea than trying to use FFADO for discovery from the start as the
audiofire discovery code can be fairly straightforward.
Once an ALSA streaming driver is available for the audiofire, it will
not be too difficult to adapt it such that it uses FFADO for device
discovery. This should make it work with all devices that use
IEC61883/AMDTP streaming (i.e. bebob, dice and oxford based devices).
I'm already restructuring the FFADO codebase to support an external
streaming engine. This should make it easy to glue things together once
the kernel driver is ready.
In any case I'm pretty happy that someone with ALSA experience takes on
the task of writing a kernel driver, because if I have to do it it would
probably take another two years.
Greets,
Pieter
PS: An ALSA driver for firewire devices will solve quite some issues
with respect to user experience and compatibility. Nevertheless I'm
personally still inclined to maintain and improve the userspace jack
streaming engine, and also port it to the new firewire stack. I'm not
convinced that things like hot-plugging, device aggregation and
sample-accurate midi will be easy to implement using
jack->ALSA->firewire. So maybe you should worry more about the confusion
that might cause...
Firewire devices are currently supported only by
FFADO (i.e., only with
Jack); I'm writing an ALSA driver for Echo devices right now, based on
my AudioFire2.
uh-oh. no chance we could convince you to instead help Pieter move the
streaming part of FFADO into the kernel so that it can be used by
ALSA? Apparently the core part of this has already been done.
24 Jan
24 Jan
3:32 p.m.
Hi,
On Saturday 23 January 2010 23:05:16 Pieter Palmers wrote:
PS: An ALSA driver for firewire devices will solve
quite some issues
with respect to user experience and compatibility. Nevertheless I'm
personally still inclined to maintain and improve the userspace jack
streaming engine, and also port it to the new firewire stack. I'm not
convinced that things like hot-plugging, device aggregation and
sample-accurate midi will be easy to implement using
jack->ALSA->firewire. So maybe you should worry more about the confusion
that might cause...
I once started thinking about this:
- Does alsa support devices where channels are added and removed during
runtime? If yes, firewire would be one big device and the channels are added
when the stream is established (and the sync is stable). If not, things will
get nasty...
- Users are already confused when they have to start special mixer apps to
get their detected card running, doing the detection in some userspace to get
the device is probably more confusing for the entry-level. But that detection
app can probably be run by udev like the firmware loaders for some usb-devices.
But if alsa doesn't support adding channels at runtime, a complex configuration
app is needed...
- Why can't each firewire-device be one alsa-device? fw allows very easy
syncing of multiple cards (two ways for sync are already in the firewire
protocol), so this is widely used. When each device has its own alsa-device,
apps would need to open several devices and still get all their callbacks
combined at once (or as one callback). I don't know about the alsa internals,
but I think its easier to open one device instead of opening several and keep
track of the sync.
Have fun,
Arnold
26 Jan
26 Jan
4:49 a.m.
Pieter Palmers wrote:
...
So a "move" of the streaming part of FFADO degenerates into a re-write
anyway. And rewriting just what is needed to discover the audiofire is a
better idea than trying to use FFADO for discovery from the start as the
audiofire discovery code can be fairly straightforward.
BTW: a first version of the driver is available here:
git://git.alsa-project.org/alsa-kprivate.git fireworks
(this branch will be rebased)
At the moment, it has one fixed sample rate, no mixer controls, and
capture only (but playback already works in my even stupider userspace
test program).
PS: An ALSA driver for firewire devices will solve
quite some issues
with respect to user experience and compatibility. Nevertheless I'm
personally still inclined to maintain and improve the userspace jack
streaming engine, and also port it to the new firewire stack. I'm not
convinced that things like hot-plugging, device aggregation and
sample-accurate midi will be easy to implement using
jack->ALSA->firewire.
Hotplugging and device aggregation should work just fine, although not
both together, i.e., ALSA doesn't allow changing the stream format while
the stream is running. Is this possible with FFADO+Jack?
So maybe you should worry more about the confusion
that might cause...
While potential users might disagree, I think more choice is better.
Best regards,
Clemens
27 Jan
27 Jan
2:33 a.m.
Clemens Ladisch wrote:
With the current version of FFADO this is not possible as bus resets are
not handled properly. But there is no technical reason that prevents
this. Jack ports can be created and destroyed at run-time, and that's
all it takes.
The major use-case I'm thinking of is where a user inadvertently unplugs
the device. With current FFADO this is a show stopper, but I'd like to
see a system that keeps running and restores everything once the device
is re-attached.
Most likely users won't care as long as it works (at least that's how I
look at things I didn't develop myself). The challenge will therefore be
to ensure that both systems can co-exist.
Greets,
Pieter
Pieter Palmers wrote:
Thanks for the repo, I'll check it out tonight.
Talking about mixer controls: do you intend to expose all mixer controls
to ALSA, or would a custom application still be the way to go for
mixers?. Can ALSA handle mixer capabilities that change with changing
device configurations?
...
So a "move" of the streaming part of FFADO degenerates into a re-write
anyway. And rewriting just what is needed to discover the audiofire is a
better idea than trying to use FFADO for discovery from the start as the
audiofire discovery code can be fairly straightforward.
BTW: a first version of the driver is available here:
git://git.alsa-project.org/alsa-kprivate.git fireworks
(this branch will be rebased)
At the moment, it has one fixed sample rate, no mixer controls, and
capture only (but playback already works in my even stupider userspace
test program). PS: An ALSA driver for firewire devices will
solve quite some issues
with respect to user experience and compatibility. Nevertheless I'm
personally still inclined to maintain and improve the userspace jack
streaming engine, and also port it to the new firewire stack. I'm not
convinced that things like hot-plugging, device aggregation and
sample-accurate midi will be easy to implement using
jack->ALSA->firewire.
Hotplugging and device aggregation should work just fine, although not
both together, i.e., ALSA doesn't allow changing the stream format while
the stream is running. Is this possible with FFADO+Jack? So maybe you should worry more about the
confusion that might cause...
While potential users might disagree, I think more choice is better.
3:59 a.m.
Pieter Palmers wrote:
If Jack cannot fix a xrun immediately by restarting, it dies. If the
device stays unplugged, waiting indefinitely for it to reappear would
make no sense. This cannot be handled without asking the user.
Most likely users won't care as long as it works (at least that's how I
look at things I didn't develop myself). The challenge will therefore be
to ensure that both systems can co-exist.
I can see the bug report: "I started both Jack+firewire and some ALSA
program, but the output wasn't properly mixed." ;-)
Best regards,
Clemens
Talking about mixer controls: do you intend to expose
all mixer controls
Yes.
to ALSA,
x*y monitoring controls would suck in a 'normal' mixer application.
or would a custom application still be the way to go
for mixers?
Yes. In theory, it shouldn't be difficult to make the existing (if any)
custom mixer work with both drivers.
Can ALSA handle mixer capabilities that change with
changing device
configurations?
Yes; mixer controls can be changed, created and destroyed at runtime.
Hotplugging
and device aggregation should work just fine, although not
both together, i.e., ALSA doesn't allow changing the stream format while
the stream is running. Is this possible with FFADO+Jack?
With the current version of FFADO this is not possible as bus resets are
not handled properly. But there is no technical reason that prevents
this. Jack ports can be created and destroyed at run-time, and that's
all it takes.
The major use-case I'm thinking of is where a user inadvertently unplugs
the device. With current FFADO this is a show stopper, but I'd like to
see a system that keeps running and restores everything once the device
is re-attached. So maybe you should worry more about the confusion
that might cause...
While potential users might disagree, I think more choice is better.
30 Jan
30 Jan
1:38 p.m.
Clemens Ladisch wrote:
Most likely users won't care as long as it works (at least that's
how I
look at things I didn't develop myself). The challenge will therefore be
to ensure that both systems can co-exist.
I can see the bug report: "I started both Jack+firewire and some ALSA
program, but the output wasn't properly mixed." ;-)
The horror...
Personally I would not mind to use ALSA for all the streaming (and mixer
control for that matter) if it is up for it. The user support of
parallel implementations is simply too much work. But it might take some
time for that to happen (as we also have e.g. MOTU and RME streaming
protocols to take care off).
The same goes for mixer control and maybe even device discovery: if it
can be built upon ALSA, why not? I'm personally a bit skeptical about
whether you'd want (or get) the required code for this into the kernel
though. Especially for BeBoB devices its a significant.
Maximum user experience with minimal effort is what I'd like to see, and
if I have to ditch all of the current FFADO code, so be it. Linux audio
is enough of a mess already.
Greets,
Pieter
Pieter Palmers wrote:
If Jack cannot fix a xrun immediately by restarting, it dies. If the
device stays unplugged, waiting indefinitely for it to reappear would
make no sense. This cannot be handled without asking the user.
To me it makes perfect sense. I unplug the device, jack keeps running in
"dummy mode", I re-plug the device and we're good to go. Why would jack
have to die? Even more: I plug in another device and it shows up as a
new interface in the jack graph. Just like what happens if I start a new
jack client.
Note that I make abstraction of the technical implementation here, this
is merely the perspective of an end-user who couldn't care less about
technical details.
Talking about mixer controls: do you intend to
expose all mixer controls
Yes.
to ALSA,
x*y monitoring controls would suck in a 'normal' mixer application.
or would a custom application still be the way to
go for mixers?
Yes. In theory, it shouldn't be difficult to make the existing (if any)
custom mixer work with both drivers.
Can ALSA handle mixer capabilities that change
with changing device
configurations?
Yes; mixer controls can be changed, created and destroyed at runtime.
Hotplugging and device aggregation should work just fine, although not
both together, i.e., ALSA doesn't allow changing the stream format while
the stream is running. Is this possible with FFADO+Jack?
With the current version
of FFADO this is not possible as bus resets are
not handled properly. But there is no technical reason that prevents
this. Jack ports can be created and destroyed at run-time, and that's
all it takes.
The major use-case I'm thinking of is where a user inadvertently unplugs
the device. With current FFADO this is a show stopper, but I'd like to
see a system that keeps running and restores everything once the device
is re-attached. So maybe you should worry more about the confusion
that might cause...
While potential users might disagree, I think more choice is
better.
2 p.m.
On Sat, Jan 30, 2010 at 12:38 PM, Pieter Palmers <pieterp(a)joow.be> wrote:
Clemens Ladisch wrote:
the problem here is that a device would need to be represented by two
clients, not 1, in order to minimize latency.
of course, one could imagine, with the recent discussion on
multiclient apps on the jack ml, that this is actually precisely how
it should
all work:
1) jack starts
2) jack detects device existence
3) app is launched that creates
(a) one in-process client for input, if appropriate
(b) one in-process client for output, if appropriate
....
...
4) app detects device removal, shuts down - appears to other clients
like a normal client vanishing from the graph
this all sounds great except for one little technical implementation
detail: JACK needs something to *drive* the graph.
this is why the driver "client" has a special place in JACK's heart.
however, now that this idea has been raised so clearly by pieter, i
can imagine a way to do all this, rather cleanly. it needs thought,
and should probably be on the JACK ML.
--p
If Jack cannot fix a xrun immediately by
restarting, it dies. If the
device stays unplugged, waiting indefinitely for it to reappear would
make no sense. This cannot be handled without asking the user.
To me it makes perfect sense. I unplug the device, jack keeps running in
"dummy mode", I re-plug the device and we're good to go. Why would jack
have to die? Even more: I plug in another device and it shows up as a
new interface in the jack graph. Just like what happens if I start a new
jack client.
2:28 p.m.
Paul Davis wrote:
On Sat, Jan 30, 2010 at 12:38 PM, Pieter Palmers
<pieterp(a)joow.be> wrote:
The backends could still be special clients that have a split
read/process/write execution order.
Isn't it as simple as:
wait for 1 / read from 1
wait for 2 / read from 2
run graph
write 1
write 2
One challenge is phase sync, but that should be solved on the driver
layer anyway.
Clemens Ladisch wrote:
the problem here is that a device would need to be represented by two
clients, not 1, in order to minimize latency.
of course, one could imagine, with the recent discussion on
multiclient apps on the jack ml, that this is actually precisely how
it should
all work:
1) jack starts
2) jack detects device existence
3) app is launched that creates
(a) one in-process client for input, if appropriate
(b) one in-process client for output, if appropriate
....
...
4) app detects device removal, shuts down - appears to other clients
like a normal client vanishing from the graph
this all sounds great except for one little technical implementation
detail: JACK needs something to *drive* the graph.
this is why the driver "client" has a special place in JACK's heart.
If Jack cannot fix a xrun immediately by
restarting, it dies. If the
device stays unplugged, waiting indefinitely for it to reappear would
make no sense. This cannot be handled without asking the user.
To me it makes
perfect sense. I unplug the device, jack keeps running in
"dummy mode", I re-plug the device and we're good to go. Why would jack
have to die? Even more: I plug in another device and it shows up as a
new interface in the jack graph. Just like what happens if I start a new
jack client.
however, now that this idea has been raised so clearly by pieter, i
can imagine a way to do all this, rather cleanly. it needs thought,
and should probably be on the JACK ML.
Maybe take into account that the firewire driver will most likely end up
to be an ALSA driver. And that device aggregation (if not done in jack
itself) will be done with the relevant ALSA mechanism. So it might be
interesting to think about supporting this for ALSA devices in general.
It might also be interesting for USB clients. Or if you have a firewire
device that is synced with your PCI soundcard.
Greets,
Pieter
2:43 p.m.
On Sat, Jan 30, 2010 at 1:28 PM, Pieter Palmers <pieterp(a)joow.be> wrote:
The backends could still be special clients that have
a split
read/process/write execution order.
that's just it - we don't really need "special" clients at all.
Maybe take into account that the firewire driver will
most likely end up to
be an ALSA driver. And that device aggregation (if not done in jack itself)
will be done with the relevant ALSA mechanism. So it might be interesting to
think about supporting this for ALSA devices in general. It might also be
interesting for USB clients. Or if you have a firewire device that is synced
with your PCI soundcard.
we already have torben's alsa_in and alsa_out clients which can do
resampling to stay in sync with the master. these would represent a
starting point, except of course that i'm imagining in-process
clients, with and without resampling.
2:49 p.m.
That hot-plugging for jack is really a good idea.
On Saturday 30 January 2010 19:00:17 Paul Davis wrote:
this all sounds great except for one little technical
implementation
detail: JACK needs something to *drive* the graph.
this is why the driver "client" has a special place in JACK's heart.
I don't think its a problem: The "clients" that are actually hardware, drive
the jack-clock/-loop. No such client, no driving jack. Unless freewheeling
gets activated.
Will be a bit of a problem to represent that gui-wise.
Thinking one step further, all available devices could then plug into jack
when wanted/needed, from all kinds of hardware. This would mean mostly one
pci/onboard alsa/oss soundcard will pop up and all usb/firewire devices too.
While this reduces the chance of jack running without a device driving it,
this highly enhances the chance of xruns when the clocks of the devices aren't
synced.
Maybe that can be "fixed" by selecting one device as the master and do
resampling for the others...
Have fun,
Arnold
4 Feb
4 Feb
6:24 a.m.
New subject: [FFADO-devel] No more PCI!
Pieter Palmers wrote:
Clemens Ladisch wrote:
So re-plugging can be handled mostly like a new device appearing. This
means that the driver doesn't need to have support for this. (Good for
me. :-)
Pieter Palmers wrote:
To me it makes perfect sense. I unplug the device, jack keeps running in
"dummy mode", I re-plug the device and we're good to go. Why would jack
have to die? Even more: I plug in another device and it shows up as a
new interface in the jack graph. Just like what happens if I start a new
jack client. The major use-case I'm thinking of is where a
user inadvertently unplugs
the device. With current FFADO this is a show stopper, but I'd like to
see a system that keeps running and restores everything once the device
is re-attached.
If Jack cannot fix a xrun immediately by restarting, it dies. If the
device stays unplugged, waiting indefinitely for it to reappear would
make no sense. This cannot be handled without asking the user. [...]
Personally I would not mind to use ALSA for all the streaming (and mixer
control for that matter) if it is up for it. The user support of
parallel implementations is simply too much work. But it might take some
time for that to happen (as we also have e.g. MOTU and RME streaming
protocols to take care off).
The same goes for mixer control and maybe even device discovery: if it
can be built upon ALSA, why not? I'm personally a bit skeptical about
whether you'd want (or get) the required code for this into the kernel
though. Especially for BeBoB devices its a significant.
The discovery/mixer code for USB and HDA devices is already in the
kernel, and it's just as messy.
However, if that code already exists (in userspace), I wouldn't want to
duplicate it without a good reason.
> BTW: a first version of the driver is available
here:
> git://git.alsa-project.org/alsa-kprivate.git fireworks
> (this branch will be rebased)
> At the moment, it has one fixed sample rate, no mixer controls, and
> capture only
Now with playback, but still very experimental; Jack should work.
Best regards,
Clemens
5204
days inactive
5218
days old
linux-audio-user@lists.linuxaudio.org
20 comments
9 participants
participants (9)
-
Arnold Krille -
Chris Cannam -
Clemens Ladisch -
Harry Van Haaren -
Mark Knecht -
Paul Davis -
Pieter Palmers -
Sean Corbett -
toby＠tobiah.org