13 May
2013
13 May
'13
11:14 p.m.
hi List
I have an RME Multiface I/HDSP PCI card. This gives 8 balanced audio
outputs. However I require an extra 8 outputs for a specific project.
One option is to sync two Multiface/HDSP PIC card together. Although not
exactly necessary, I understand the extra hdsp card is needed if i wish
to use sampling rates higher than 48k which i do. There are some other
set up benefits too I gather.
Perhaps this is the best option for 16 outs - but can anyone suggest an
alternative interface with 16 outputs (preferably balanced) on linux?
Cheers,
14 May
14 May
12:11 a.m.
On Mon, 13 May 2013, Iain Mott wrote:
I have an RME Multiface I/HDSP PCI card. This gives 8
balanced audio
outputs. However I require an extra 8 outputs for a specific project.
I've also looked at my options for expanding beyond 8 analog i/o's on my
Multiface II....
One option is to sync two Multiface/HDSP PIC card
together. Although
not exactly necessary, I understand the extra hdsp card is needed if i
wish to use sampling rates higher than 48k which i do. There are some
other set up benefits too I gather.
Something to be aware of is that although you can have up to 3
Hammerfall cards in a single computer, they cannot share any kind of bus
for monitoring or headphones in TotalMix (or its Linux clone,
hdspmixer). You will end up with separate headphone lines, which you
may be able to merge with cabling yourself at the expense of a couple of
inputs, but that's messy.
Alternatives to getting a second Hammerfall card include:
* Taking advantage of the digital i/o's that you already have... I've
had some trouble finding the exact specs of the Multiface I, but on the
II, there is an SPDIF digital i/o (2ch. in, 2ch. out), and an ADAT port
(8ch. in, 8ch. out). The analogs, the SPDIF, and the ADAT can all be
used at the same time, but the catch is that because ADAT itself has a
48kHz limit, there's no way to use the ADAT's at 96kHz unless you bind
the 8 i/o's together as 4 virtual i/o's that each combine two channels
to get double speed (called SMUX).
Since I've seen that the Multiface's analog converters don't
really sound right (probably due to filter design) unless you run it at
96kHz, and since it's not possible to run the analog i/o's at 96kHz
while you run the digitals at another speed, the net effect of all this
boils down to that you're going to want to run at 96kHz, and if you're
using the ADAT ports at that speed, you will have to use SMUX even
though that will cut you down to 4 ADAT i/o's instead of 8.
And the net effect of all that totally is that you have the
potential for up to 14 i/o's if you put all the analogs,
SMUX'ed-together ADAT's, and the SPDIF l/r pair together and use them
all, from one Hammerfall card. Not quite the 16 analog i/o's you'd get
from having two Hammerfall's, but at least it all ends up in one unified
TotalMix/hdspmixer session with one headphone monitor.
There is one further complication: There aren't a lot of
8-channel standalone ADAT AD/DA's out there that I've seen that aren't
either rediculous expensive or suspiciously cheap. It's amazing how
much you might end up paying for those 4 SMUX'ed i/o's if you go this
route. RME themselves make one, but it's one of the expensive ones, and
oddly, it costs way more than getting a whole second
Hammerfall/Multiface setup even though it does far less. (But again, if
you get that second Hammerfall, it will have its own separate busses in
TotalMix.)
* You can go with RME MADI, which is MADIly expensive, but has an insane
channel count. Sadly, as far as I know, there's no support in Linux for
TotalMix or anything like it if you go this route, though it is driver
compatible with Alsa and Jack. You just won't have any GUI mixer like
hdspmixer, which would kind of stink, especially on such pro-grade
hardware.
* You could get someone else's audio hardware, perhaps taking adventage
of FFADO to get it done by firewire...but then you'd lose the stability
and it-just-works experience that you get from the RME Multiface on
Linux. Or you could take a chance on USB, which is becoming more and
more popular despite that it reminds me of trying to use a Volkswagon
Bug for an Antarctic polar expedition.
All of the above is why, for the moment, I'm just living with my 8
analog i/o's and dealing with it. :-/ At least the analog i/o's the
one Multiface comes with just work, and splendidly.
--
+ Brent A. Busby + "We've all heard that a million monkeys
+ Sr. UNIX Systems Admin + banging on a million typewriters will
+ University of Chicago + eventually reproduce the entire works of
+ James Franck Institute + Shakespeare. Now, thanks to the Internet,
+ Materials Research Ctr + we know this is not true." -Robert Wilensky
12:46 a.m.
Thanks Brent and Ralf. I also wrote to the RME forum. Seems that even if
I do get a new MF/HDSP combo - one of the respondents thought the sync
wouldn't be sample-accurate if I were to combine an MFI with an MFII. He
thought it would though if I got hold of a second MFI - but wasn't sure.
I'm waiting to see if anyone from RME confirms. Does anyone here have an
opinion on that? I'd rather not buy a used MFI - as things often go
missing in the post in Brazil - and taxes on used imports are huge.
Does anyone on the list have a 16-out system running on linux - with
firewire, usb or otherwise?
Just came across some info on the Allen and Heath ICE-16. Looks great
but couldn't find anything about linux drivers... Also has unbalanced
outs - but I'll be using short cables to multichannel amps so that
should be Ok.
cheers,
Em Seg, 2013-05-13 às 17:11 -0500, Brent Busby escreveu:
On Mon, 13 May 2013, Iain Mott wrote:
I have an RME Multiface I/HDSP PCI card. This
gives 8 balanced audio
outputs. However I require an extra 8 outputs for a specific project.
I've also looked at my options for expanding beyond 8 analog i/o's on my
Multiface II....
One option is to sync two Multiface/HDSP PIC card
together. Although
not exactly necessary, I understand the extra hdsp card is needed if i
wish to use sampling rates higher than 48k which i do. There are some
other set up benefits too I gather.
Something to be aware of is that although you can have up to 3
Hammerfall cards in a single computer, they cannot share any kind of bus
for monitoring or headphones in TotalMix (or its Linux clone,
hdspmixer). You will end up with separate headphone lines, which you
may be able to merge with cabling yourself at the expense of a couple of
inputs, but that's messy.
Alternatives to getting a second Hammerfall card include:
* Taking advantage of the digital i/o's that you already have... I've
had some trouble finding the exact specs of the Multiface I, but on the
II, there is an SPDIF digital i/o (2ch. in, 2ch. out), and an ADAT port
(8ch. in, 8ch. out). The analogs, the SPDIF, and the ADAT can all be
used at the same time, but the catch is that because ADAT itself has a
48kHz limit, there's no way to use the ADAT's at 96kHz unless you bind
the 8 i/o's together as 4 virtual i/o's that each combine two channels
to get double speed (called SMUX).
Since I've seen that the Multiface's analog converters don't
really sound right (probably due to filter design) unless you run it at
96kHz, and since it's not possible to run the analog i/o's at 96kHz
while you run the digitals at another speed, the net effect of all this
boils down to that you're going to want to run at 96kHz, and if you're
using the ADAT ports at that speed, you will have to use SMUX even
though that will cut you down to 4 ADAT i/o's instead of 8.
And the net effect of all that totally is that you have the
potential for up to 14 i/o's if you put all the analogs,
SMUX'ed-together ADAT's, and the SPDIF l/r pair together and use them
all, from one Hammerfall card. Not quite the 16 analog i/o's you'd get
from having two Hammerfall's, but at least it all ends up in one unified
TotalMix/hdspmixer session with one headphone monitor.
There is one further complication: There aren't a lot of
8-channel standalone ADAT AD/DA's out there that I've seen that aren't
either rediculous expensive or suspiciously cheap. It's amazing how
much you might end up paying for those 4 SMUX'ed i/o's if you go this
route. RME themselves make one, but it's one of the expensive ones, and
oddly, it costs way more than getting a whole second
Hammerfall/Multiface setup even though it does far less. (But again, if
you get that second Hammerfall, it will have its own separate busses in
TotalMix.)
* You can go with RME MADI, which is MADIly expensive, but has an insane
channel count. Sadly, as far as I know, there's no support in Linux for
TotalMix or anything like it if you go this route, though it is driver
compatible with Alsa and Jack. You just won't have any GUI mixer like
hdspmixer, which would kind of stink, especially on such pro-grade
hardware.
* You could get someone else's audio hardware, perhaps taking adventage
of FFADO to get it done by firewire...but then you'd lose the stability
and it-just-works experience that you get from the RME Multiface on
Linux. Or you could take a chance on USB, which is becoming more and
more popular despite that it reminds me of trying to use a Volkswagon
Bug for an Antarctic polar expedition.
All of the above is why, for the moment, I'm just living with my 8
analog i/o's and dealing with it. :-/ At least the analog i/o's the
one Multiface comes with just work, and splendidly.
1:18 a.m.
On Mon, 2013-05-13 at 19:52 -0300, Iain Mott wrote:
one of the respondents thought the sync wouldn't
be sample-accurate
This deviation is that small, that it's comparable to a minimal
difference, of the position of two microphones. For clean stereo IO
pairs simply use IO pairs just from one device and don't mix both
devices for a stereo pair. Likely that both aren't sample accurate,
unlikely that it will be an issue.
1:44 a.m.
I didn't mention that it's an ambisonic application, projecting B-format
recordings and 2nd and 3rd order simulations - wouldn't this present
problems?
Em Ter, 2013-05-14 às 01:17 +0200, Ralf Mardorf escreveu:
On Mon, 2013-05-13 at 19:52 -0300, Iain Mott wrote:
one of the respondents thought the sync
wouldn't be sample-accurate
This deviation is that small, that it's comparable to a minimal
difference, of the position of two microphones. For clean stereo IO
pairs simply use IO pairs just from one device and don't mix both
devices for a stereo pair. Likely that both aren't sample accurate,
unlikely that it will be an issue.
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
1:50 a.m.
On Mon, 2013-05-13 at 20:50 -0300, Iain Mott wrote:
I didn't mention that it's an ambisonic
application, projecting B-format
recordings and 2nd and 3rd order simulations - wouldn't this present
problems?
I would wait for an answer from RME and wait until the ambisonic folks
from this list will answer. I don't know, but I don't think so.
6:35 a.m.
Iain,
Thanks Brent and Ralf. I also wrote to the RME forum.
Seems that even if
I do get a new MF/HDSP combo - one of the respondents thought the sync
wouldn't be sample-accurate if I were to combine an MFI with an MFII. He
thought it would though if I got hold of a second MFI - but wasn't sure.
The Multiface 1 and 2 have different converters. Depending on what you
want to achieve, this is probably not what you want (the converters in
the Multiface 2 are faster).
What do you mean with "the sync wouldn't be sample-accurate"? Multiple
cards can be started and stopped at exactly the same buffer position.
Flo
--
Machines can do the work, so people have time to think.
public key B3B9226C
11:04 a.m.
Hi Flo,
This is what was said:
"The MF-I and MF-II's AD/DA conversion latencies vary slightly (MF-II is
slightly quicker) - you won't get "Sample accurate" I/O across MF-I to
MF-II"
You mention the multiface 2 is faster too. Will there be a
problem-causing delay between the multiface 1 and 2 channels, a
difference in sound quality, or both?
What would be your suggestion for 16 outs on linux?
I'm not necessarily limited to expanding upon the Multiface/HDSP that I
already have for this project, although saving money is certainly a good
thing!
Thanks,
Iain
Em Ter, 2013-05-14 às 06:34 +0200, Florian Faber escreveu:
The Multiface 1 and 2 have different converters.
Depending on what you
want to achieve, this is probably not what you want (the converters in
the Multiface 2 are faster).
What do you mean with "the sync wouldn't be sample-accurate"? Multiple
cards can be started and stopped at exactly the same buffer position.
11:21 a.m.
On Tue, 2013-05-14 at 06:10 -0300, Iain Mott wrote:
Hi Flo,
This is what was said:
"The MF-I and MF-II's AD/DA conversion latencies vary slightly (MF-II is
slightly quicker) - you won't get "Sample accurate" I/O across MF-I to
MF-II"
But Flo does get sample accuracy :D or was he floing?!
You mention the multiface 2 is faster too. Will there
be a
problem-causing delay between the multiface 1 and 2 channels, a
difference in sound quality, or both?
Is there no dealer near to you, who enables testing?
For my RME to ADAT sync by ADAT, not WC, is audible, if I use one IO
from the RME and the other from the ADA8000. I wouldn't use it that way,
but I guess sync between the MFs could be much better. Somebody from RME
would use such a combination (RME AIO + ADA8000 one IO from each
device), since it's still like moving a microphone a little bit.
Tastes differ!
What would be your suggestion for 16 outs on linux?
I'm not necessarily limited to expanding upon the Multiface/HDSP that I
already have for this project, although saving money is certainly a good
thing!
Thanks,
Iain
Em Ter, 2013-05-14 às 06:34 +0200, Florian Faber escreveu:
The Multiface 1 and 2 have different converters.
Depending on what you
want to achieve, this is probably not what you want (the converters in
the Multiface 2 are faster).
What do you mean with "the sync wouldn't be sample-accurate"? Multiple
cards can be started and stopped at exactly the same buffer position.
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
11:49 a.m.
Iain,
You mention the multiface 2 is faster too. Will there
be a
problem-causing delay between the multiface 1 and 2 channels, a
difference in sound quality, or both?
Of course the sound output is different on a measurable scale. Wether it
is on a scale that might cause problems for your use case, I doubt. The
tolerances of your amps and speakers might be bigger by a few magnitudes.
What would be your suggestion for 16 outs on linux?
Do you want to expand that channel number in the future? In that case it
would probably make more sense to get an interface that gives you more
channels in the first place instead of maxing out a smaller interface
and having to throw it away in the next expansion step.
I'm not necessarily limited to expanding upon the
Multiface/HDSP that I
already have for this project, although saving money is certainly a good
thing!
The cheapest solution with exactly the same output characteristics:
Get a second used Multiface I and use it as ADAT->Analogue converter
box. Measure the ADAT transport delay (should be in whole samples) and
compensate the latency. Done.
Flo
--
Machines can do the work, so people have time to think.
public key B3B9226C
12:04 p.m.
On Tue, 2013-05-14 at 11:49 +0200, Florian Faber wrote:
Measure the ADAT transport delay (should be in whole
samples) and
compensate the latency.
A serious question. How can the latency be compensated that exactly? For
e.g. Qtractor the latency automatically and manually compensation isn't
that exact. Can this be done by hdspconf? I don't know hdspconf, since
it doesn't work for my RME card.
12:17 p.m.
What would be your suggestion for 16 outs on
linux?
Do you want to expand that channel number in the future? The cheapest solution with exactly the same output
characteristics:
Get a second used Multiface I and use it as ADAT->Analogue converter
box. Measure the ADAT transport delay (should be in whole samples) and
compensate the latency. Done.
The MF-I is hard to come by here - and as I mentioned - importing things
through international mail is subject to a heavy tax (even used
equipment) and sometimes items are stolen (it's happened more than once
to me).
Ralf mentioned that syncing with a ADA8000 via the ADAT produces an
audible difference. Is Word clock syncing more reliable? I know matching
a MF-I and the ADA8000 will likely result in different output
characteristics and be limited to 48kHz audio - but these units are
readily available here and quite cheap. It's tempting. Do you have an
opinion?
And Ralf, no, unfortunately I can't test RME equipment in this or any
nearby city.
cheers,
Iain
1:13 p.m.
It's said that WC is more accurate, but the main issue is what Flo
pointed out. Different hardware needs a fine tuning regarding to the
latency compensation.
I don't measure what I get for ADAT sync without WC here, but there's an
audible phase shift. Using one output from the RME and the other from
the ADA, the stereo effect is wider. I didn't test, if this will cause
serious issues for mixing, especially when the channels will be routed
to mono.
For Qtractor you at best can be exact to the ms, but even this isn't
always possible and a compensation < 1ms is impossible using Qtractor.
So it's a serious question, how to compensate latency to get it sample
accurate.
I don't know what can be done by the RME tools, since my card isn't good
supported for Linux at the moment.
During the night and morning I installed a XP to do some tests, but I've
got issues creating a working graphics driver and Internet
connection :(. There are no issues running XP in VBox on Linux, but that
doesn't help, for testing the RME hardware and tools.
I agree with Flo that the tolerances of your amps and speakers likely is
bigger, but since it's a chain, it might add phase shift, even if it
shouldn't be audible for the mix, doing the mastering becomes harder,
the more similar issues are added.
2:31 p.m.
On Tue, 14 May 2013 07:23:18 -0300
Iain Mott <mott(a)reverberant.com> wrote:
It's a possibility. I am curious to know what
16-out or higher systems
work on Linux?
I have 16 balanced outs by running two M-Audio Delta 1010s synced together.
It's been very stable for me at 48k, never tried higher sample rates.
Not exactly the cheapest solution, but to tie this together with another
thread, the external breakout box on the 1010 is prone to having its
capacitors fail. I got my second 1010 for free when a list member offered
to give me one that had failed if I documented the repair. You may be able
to get a couple that need repairing cheaply.
I have the repair documentation as well as my experiences on syncing the
two up with the S/PDIF ports at http://delta.brainiac.com
--
======================================================================
Joe Hartley - UNIX/network Consultant - jh(a)brainiac.com
Without deviation from the norm, "progress" is not possible. - FZappa
4:09 p.m.
Iain!
It's a
possibility. I am curious to know what 16-out or higher systems
work on Linux?
PCI-only, and just audio interfaces (ie bridging to some audio standard
format):
RME: RayDAT (24), AES (32), MADI (64), MADIFX (192)
Marian: A3 (24), M2 (128)
There's also an ethersound interface supported.
In all those cases you would need an external converter. All those
solutions would cost much more than just a cheap ADAT converter or a
second Multiface.
Packet insurances exist, so who cares?
What would be your suggestion for 16 outs on linux?
Do you want to expand that channel number in the future? The cheapest
solution with exactly the same output characteristics:
Get a second used Multiface I and use it as ADAT->Analogue converter
box. Measure the ADAT transport delay (should be in whole samples) and
compensate the latency. Done.
The MF-I is hard to come by here - and as I
mentioned - importing things
through international mail is subject to a heavy tax (even used
equipment) and sometimes items are stolen (it's happened more than once
to me). Ralf mentioned that syncing with a ADA8000 via the
ADAT produces an
audible difference.
I have no experience with such crap gear.
Flo
--
Machines can do the work, so people have time to think.
public key B3B9226C
4:34 p.m.
The cheapest solution with exactly the same output characteristics:
Get a second used Multiface I and use it as ADAT->Analogue converter
box. Measure the ADAT transport delay (should be in whole samples) and
compensate the latency. Done.
Flo, Thanks for all the advice - and I guess you're right - I should
really look for another MF-I. Just one more question (I hope) : how will
I measure the ADAT transport delay?
Iain
5:05 p.m.
Iain!
Flo, Thanks for all the advice - and I guess
you're right - I should
really look for another MF-I. Just one more question (I hope) : how will
I measure the ADAT transport delay?
jack_delay for example. You add one ADAT loop to your first MF, and then
the second MF with ADAT loop. The difference should be twice the
transport latency.
http://wiki.linuxproaudio.org/index.php/Howto:latency_measurement
Flo
--
Machines can do the work, so people have time to think.
public key B3B9226C
5:06 p.m.
On Tue, May 14, 2013 at 11:40:23AM -0300, Iain Mott wrote:
>
> The cheapest solution with exactly the same output characteristics:
> Get a second used Multiface I and use it as ADAT->Analogue converter
> box. Measure the ADAT transport delay (should be in whole samples) and
> compensate the latency. Done.
Flo, Thanks for all the advice - and I guess
you're right - I should
really look for another MF-I. Just one more question (I hope) : how will
I measure the ADAT transport delay?
First do
jack_delay -> MF-A analog out -> MF->A analog in -> jack_delay
then
jack_delay -> MF-A adat out -> MF-B adat in -> MF-B analog out -> MF-A
analog in -> jack_delay.
The difference is the ADAT transport delay. You could use a MF II as well.
If you are using this for an Ambisonic setup you can let Ambdec do the
delay compensation : in the Ambdec config, add the extra delay converted
to distance at the speed of sound to the distances of the speakers connected
to the second box, and enable distance compensation.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
15 May
15 May
9:06 p.m.
On 05/14/2013 11:10 AM, Iain Mott wrote:
Hi Flo,
This is what was said:
"The MF-I and MF-II's AD/DA conversion latencies vary slightly (MF-II is
slightly quicker) - you won't get "Sample accurate" I/O across MF-I to
MF-II"
unless you have exactly one listener and literally tie him/her in place
in the exact sweet spot, one or two samples of difference will not pose
much of a problem. furthermore, you can easily measure the latencies
using jack_delay and compensate for them.
--
Jörn Nettingsmeier
Lortzingstr. 11, 45128 Essen, Tel. +49 177 7937487
Meister für Veranstaltungstechnik (Bühne/Studio)
Tonmeister VDT
http://stackingdwarves.net
14 May
14 May
6:32 a.m.
Brent,
* You can go with RME MADI, which is MADIly expensive,
but has an insane
channel count. Sadly, as far as I know, there's no support in Linux for
TotalMix or anything like it if you go this route, though it is driver
compatible with Alsa and Jack. You just won't have any GUI mixer like
hdspmixer, which would kind of stink, especially on such pro-grade
hardware.
If you don't know something, please at least don't spread wrong
information. You are mardorfing there.
Flo
--
Machines can do the work, so people have time to think.
public key B3B9226C
2:58 p.m.
On Tue, 14 May 2013, Florian Faber wrote:
Brent,
Does hdspmixer support a MADI with 32 or 64 channels? Will its GUI even
display a thing like that?
--
+ Brent A. Busby + "We've all heard that a million monkeys
+ Sr. UNIX Systems Admin + banging on a million typewriters will
+ University of Chicago + eventually reproduce the entire works of
+ James Franck Institute + Shakespeare. Now, thanks to the Internet,
+ Materials Research Ctr + we know this is not true." -Robert Wilensky
* You can go with RME MADI, which is MADIly
expensive, but has an insane
channel count. Sadly, as far as I know, there's no support in Linux for
TotalMix or anything like it if you go this route, though it is driver
compatible with Alsa and Jack. You just won't have any GUI mixer like
hdspmixer, which would kind of stink, especially on such pro-grade
hardware.
If you don't know something, please at least don't spread wrong
information. You are mardorfing there.
3:01 p.m.
Brent,
Yes and yes. I am pretty sure I know this first-hand :)
Flo
--
Machines can do the work, so people have time to think.
public key B3B9226C
If you
don't know something, please at least don't spread wrong
information. You are mardorfing there.
Does hdspmixer support a MADI with 32 or 64
channels? Will its GUI even
display a thing like that?
3:12 p.m.
On Tue, 14 May 2013, Florian Faber wrote:
Brent,
Yes and yes. I am pretty sure I know this first-hand :)
Ok sorry about the mix-information then. I thought its Windows/Mac
mixer app was a whole different program for which there was no Linux
clone.
(On the bright side, that means I might think about MADI myself
then...if I ever get that kind of money...)
--
+ Brent A. Busby + "We've all heard that a million monkeys
+ Sr. UNIX Systems Admin + banging on a million typewriters will
+ University of Chicago + eventually reproduce the entire works of
+ James Franck Institute + Shakespeare. Now, thanks to the Internet,
+ Materials Research Ctr + we know this is not true." -Robert Wilensky
If you
don't know something, please at least don't spread wrong
information. You are mardorfing there.
Does hdspmixer support a MADI with 32 or 64
channels? Will its GUI even
display a thing like that?
3:18 p.m.
Brent,
Ok sorry about the mix-information then. I thought
its Windows/Mac
mixer app was a whole different program for which there was no Linux clone.
It has less features than the current Windows/OS X implementations. It
was a clone of the first generation of TotalMix.
More complex matrix setups should probably not be set up by this kind of
intetrface anyway, and since Windows/OS X users don't have a simple way
to control their cards through the shell or other applications, I don't
see any drawbacks, quite the opposite :)
Flo
--
Machines can do the work, so people have time to think.
public key B3B9226C
3:05 p.m.
Brent,
Does hdspmixer support a MADI with 32 or 64 channels?
Will its GUI even
display a thing like that?
I just checked: I added support in April 2009, released it in September
2009 and added AIO and RayDAT support 2010-07-01. Adrian then merged it
into alsa-tools 1.0.24.
Any further questions you could have found out with 30s of googling
yourself?
Flo
--
Machines can do the work, so people have time to think.
public key B3B9226C
3:15 p.m.
On Tue, 14 May 2013, Florian Faber wrote:
I just checked: I added support in April 2009,
released it in
September 2009 and added AIO and RayDAT support 2010-07-01. Adrian
then merged it into alsa-tools 1.0.24.
Any further questions you could have found out with 30s of googling
yourself?
Actually, the information I found to the effect that it's not supported
was from googling, but apparently it was older than that.
Again, sorry for the confusion...
--
+ Brent A. Busby + "We've all heard that a million monkeys
+ Sr. UNIX Systems Admin + banging on a million typewriters will
+ University of Chicago + eventually reproduce the entire works of
+ James Franck Institute + Shakespeare. Now, thanks to the Internet,
+ Materials Research Ctr + we know this is not true." -Robert Wilensky
4:21 p.m.
New subject: OT: RME Multiface and an extra 8 output channels
On Tue, 2013-05-14 at 15:05 +0200, Florian Faber wrote:
and added AIO and RayDAT support 2010-07-01. Adrian
then merged it
into alsa-tools 1.0.24.
I wonder if there are different revisions. I started with 1.0.24 and
there were no improvements until now, 1.0.27.
[rocketmouse@archlinux ~]$ hdspconf
HDSPConf 1.4 - Copyright (C) 2003 Thomas Charbonnel <thomas(a)undata.org>
This program comes WITH ABSOLUTELY NO WARRANTY
HDSPConf is free software, see the file copying for details
Looking for HDSP cards :
Card 0 : RME AIO S/N 0x579bcc at 0xfddf0000, irq 18
Card 1 : TerraTec EWX24/96 at 0xbf00, irq 20
Card 2 : TerraTec EWX24/96 at 0xbb00, irq 21
No Hammerfall DSP card found.
[rocketmouse@archlinux ~]$ hdspmixer
HDSPMixer 1.11 - Copyright (C) 2003 Thomas Charbonnel
<thomas(a)undata.org>
This program comes with ABSOLUTELY NO WARRANTY
HDSPMixer is free software, see the file COPYING for details
Looking for RME cards:
Card 0: RME AIO S/N 0x579bcc at 0xfddf0000, irq 18
RME AIO found!
Card 1: TerraTec EWX24/96 at 0xbf00, irq 20
Card 2: TerraTec EWX24/96 at 0xbb00, irq 21
1 RME cards card found.
Restoring last presets used
hdspmixer doesn't work correctly and alsamixer doesn't work correctly
either.
Is the board revision of the AIO important or is it known not to work
with some mobos or something like that?
15 May
15 May
9:04 p.m.
On 05/13/2013 08:35 PM, Iain Mott wrote:
hi List
I have an RME Multiface I/HDSP PCI card. This gives 8 balanced audio
outputs. However I require an extra 8 outputs for a specific project.
One option is to sync two Multiface/HDSP PIC card together. Although not
exactly necessary, I understand the extra hdsp card is needed if i wish
to use sampling rates higher than 48k which i do. There are some other
set up benefits too I gather.
iain, are you absolutely sure you need sample rates above 48k? i'd be
curious to hear more about your usecase.
if you really do, e.g. for creating ultrasonics, then the only solution
that comes to mind is an rme hdspm plus a pricey converter for 96 or
even 192 khz, such as two adi-qs or an m16.
--
Jörn Nettingsmeier
Lortzingstr. 11, 45128 Essen, Tel. +49 177 7937487
Meister für Veranstaltungstechnik (Bühne/Studio)
Tonmeister VDT
http://stackingdwarves.net
9:12 p.m.
Joern,
if you really do, e.g. for creating ultrasonics,
Running at 192 or 96 kHz gives the theoretical bandwidth, yes, but they
are *audio* converters. There are not many chips that convert the
theoretically possible bandwidth. The M16 e.g. does only 50kHz at 192kHz
and 34kHz at 96kHz.
I once had a couple of very disappointed bat biologists who wanted to
use the M32AD :)
then the only solution
that comes to mind is an rme hdspm plus a pricey converter for 96 or
even 192 khz, such as two adi-qs or an m16.
Way too expensive. There are 32ch converters on the market for a quarter
of that price.
Flo
--
Machines can do the work, so people have time to think.
public key B3B9226C
10:04 p.m.
"Way too expensive. There are 32ch converters on the market for a quarter
of that price."
But man, does it sound amazing! I've currently got one ADI8-QS and as soon
as I can afford it, I'll be getting another. Expensive, but yummy!
--Jason
www.artcitysound.com
On May 15, 2013 1:12 PM, "Florian Faber" <faber(a)faberman.de> wrote:
Joern,
if you really do, e.g. for creating ultrasonics,
Running at 192 or 96 kHz gives the theoretical bandwidth, yes, but they
are *audio* converters. There are not many chips that convert the
theoretically possible bandwidth. The M16 e.g. does only 50kHz at 192kHz
and 34kHz at 96kHz.
I once had a couple of very disappointed bat biologists who wanted to
use the M32AD :)
then the only solution
that comes to mind is an rme hdspm plus a pricey converter for 96 or
even 192 khz, such as two adi-qs or an m16.
Way too expensive. There are 32ch converters on the market for a quarter
of that price.
Flo
--
Machines can do the work, so people have time to think.
public key B3B9226C
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
16 May
16 May
10:16 a.m.
On Wed, 2013-05-15 at 21:04 +0200, Jörn Nettingsmeier wrote:
iain, are you absolutely sure you need sample rates
above 48k? i'd be
curious to hear more about your usecase.
if you really do, e.g. for creating ultrasonics, then the only solution
that comes to mind is an rme hdspm plus a pricey converter for 96 or
even 192 khz, such as two adi-qs or an m16.
Perhaps the noise floor at higher sample rates could be an issue for the
OP.
Sometimes higher sample rates allow to use a lower latency, for my RME
card, another model, not the MF, it's not like that, if I set it to
higher sample rates, the frames/period automagically becomes higher too.
IMO 48 KHz is high enough, not only for my home studio, also for
professional usage.
FWIW, since my card still is within the warranty period I'm testing if
everything does work on a Windows I installed to do the tests. I noticed
that for sample rates from 32 KHz to 96 KHz nothing connected to the
analog inputs of the card, the noise floor shown by TotalMix is at -110
[1] and for sample rates from 128 KHz to 192 KHz it's at -54. If I
connect an elCheapo no-name device, the noise floor for sample rates
from 32 KHz to 96 KHz does raise to -87.
Even if I would use sample rates higher than 48 KHz, it would be ok for
my taste, but it's not what you want for professional usage.
A Yamaha MT 44D, a 4-Track cassette recorder already has a better SNR
[2].
[1] From the user manual: "(SNR): 113 dB RMS unweighted, 116 dBA @ 44.1
KHz", no information about the SNR for other sample rates.
[2] From the service manual: "Signal-to-Noise Ratio (EIAJ) (Dolby OFF)
55 dB", "(Dolby C ON) 67 dB".
So at least the card I'm using has got a noise floor for sample rates
96 KHz, that perhaps isn't ok for the OPs needs.
Perhaps it's not like that for more expensive RME cards.
Regards,
Ralf
10:27 a.m.
PS: I'm comparing what I see by the meters and what "I" call "noise
floor", with the SNR by manuals, perhaps not really a valid
comparison ;), but it's IMO still a pointer.
17 May
17 May
10:58 a.m.
On 05/16/2013 10:16 AM, Ralf Mardorf wrote:
On Wed, 2013-05-15 at 21:04 +0200, Jörn Nettingsmeier
wrote:
<snip>
iain, are you absolutely sure you need sample
rates above 48k? i'd be
curious to hear more about your usecase.
if you really do, e.g. for creating ultrasonics, then the only solution
that comes to mind is an rme hdspm plus a pricey converter for 96 or
even 192 khz, such as two adi-qs or an m16.
Perhaps the noise floor at higher sample rates could be an issue for the
OP. FWIW, since my card still is within the warranty
period I'm testing if
everything does work on a Windows I installed to do the tests. I noticed
that for sample rates from 32 KHz to 96 KHz nothing connected to the
analog inputs of the card, the noise floor shown by TotalMix is at -110
[1] and for sample rates from 128 KHz to 192 KHz it's at -54. If I
connect an elCheapo no-name device, the noise floor for sample rates
from 32 KHz to 96 KHz does raise to -87.
Even if I would use sample rates higher than 48 KHz, it would be ok for
my taste, but it's not what you want for professional usage.
A Yamaha MT 44D, a 4-Track cassette recorder already has a better SNR
[2].
[1] From the user manual: "(SNR): 113 dB RMS unweighted, 116 dBA @ 44.1
KHz", no information about the SNR for other sample rates.
[2] From the service manual: "Signal-to-Noise Ratio (EIAJ) (Dolby OFF)
55 dB", "(Dolby C ON) 67 dB".
So at least the card I'm using has got a noise floor for sample rates
> 96 KHz, that perhaps isn't ok for the OPs needs.
sigh. ralf, the "noise floor" is a function of the bandwidth. if you
double the bandwidth, you will more or less double the total energy of
the noise.
incidentally, you will also double the energy of the signal.
and "measuring" a preamp/ad stage with open connectors says precisely
_nothing_ about the quality of the stage but a lot about the person
doing the measuring.
really, the amount of misinformation you are spreading here is
unbelievable. talking nonsense is ok every once in a while (says this
expert nonsense talker who's been wrong in public a thousand times). but
launching a steady stream of mails all the time in which almost every
single statement of fact is wrong, that's another matter. if you come
across an interesting question (like how come the apparent snr is so bad
for pro equipment at high sample rates), then post it as a _question_.
don't confuse other users with false statements.
oh, and maybe sometimes it is an option not to post at all.
--
Jörn Nettingsmeier
Lortzingstr. 11, 45128 Essen, Tel. +49 177 7937487
Meister für Veranstaltungstechnik (Bühne/Studio)
Tonmeister VDT
http://stackingdwarves.net
11:18 a.m.
On Fri, 2013-05-17 at 10:58 +0200, Jörn Nettingsmeier wrote:
"measuring" a preamp/ad stage with open
connectors says precisely
_nothing_ about the quality of the stage but a lot about the person
doing the measuring.
Don't worry, I'm aware abut this :D, I might have developed equipment
you are using for your work as Tonmeister VDT :p.
really, the amount of misinformation you are spreading
here is
unbelievable.
No it isn't, I just pointed out, that 48 KHz usually is what is needed
and that increasing the sample frequency will increase noise.
11:08 p.m.
On Fri, May 17, 2013 at 11:18:08AM +0200, Ralf Mardorf wrote:
In the analog world, increasing bandwidth while everything else
is fixed will increase thermal noise power. Noise density will
remain the same, and that's the only thing that matters.
In the digital world, increasing the sample rate while keeping the
number of bits the same means the same quantisation noise power
will be spread over a larger BW, and noise density will go down.
If you measure anything else then either your measurement is bogus
or the equipment you're testing is broken.
Some of your remarks on the audio world in general may be to the
point, and I could even agree with some of them, but this talk
about noise is complete nonsense.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
On Fri, 2013-05-17 at 10:58 +0200, Jörn Nettingsmeier
wrote:
If you are aware of the fact that your measurement methods (if any)
are completely bogus, why do you present the 'results' as facts ?
Do you really believe your own measurements ? If noise seems to
increase from -110 to -54 dB for sample rates above 128k, doesn't
that trigger even a hint of a suspicion that something could be
really wrong with the way you measure this ? No ? Nothing ? If not,
you shouldn't waste your time doing measurements of any kind - it
really requires a different attitude.
"measuring" a preamp/ad stage with open
connectors says precisely
_nothing_ about the quality of the stage but a lot about the person
doing the measuring.
Don't worry, I'm aware abut this :D, really, the
amount of misinformation you are spreading here is
unbelievable.
No it isn't, I just pointed out, that 48 KHz usually is what is needed
and that increasing the sample frequency will increase noise.
11:37 p.m.
On Fri, 17 May 2013 23:08:29 +0200, Fons Adriaensen <fons(a)linuxaudio.org>
wrote:
If you measure anything else then either your
measurement is bogus
or the equipment you're testing is broken.
Sorry I can't resist, isn't is possible, that my measurements are bogus
and that my equipment is broken?
Seriously, I just watched the meters of TotalMix and didn't measure
anything, but at least I did connect a device to the inputs ;).
I guess I should have used another choice of words.
For the RME card I own, higher sample rates don't result in lower latency.
If I increase the latency, low frames/period disappear and just higher
frames/period can be chosen (on Windows, on Linux I can't get higher than
48 KHz, since it doesn't work, seemingly a driver issue).
Somebody else pointed out that even 192 KHz don't provide to sample
ultrasonic, so it can't be used for bat research, e.g. to find out
different dialects of the same kind of bat in different areas.
If I chose higher sample rates > 96 KHz, I can see double the noise shown
by TotalMix, than with sample rates <= 96 KHz, I wasn't able to hear a
difference.
If this should be the same for other cards too, no lower latency and no
ultrasonic (for bats between 15 and 100 KHz regarding to the Internet, I
should know this without Google, since a former girlfriend did bat
research, but I needed to google), than the OP perhaps could use 48 KHz
for his needs.
I guess most of us agree, that if the gear is ok, 48 KHz are all that is
needed for audio production, music and speech.
4428
days inactive
4432
days old
linux-audio-user@lists.linuxaudio.org
36 comments
8 participants
participants (8)
-
Brent Busby -
Florian Faber -
Fons Adriaensen -
Iain Mott -
Jason Jones -
Joe Hartley -
Jörn Nettingsmeier -
Ralf Mardorf