Re: Is Linux A Feasible Platofrm For Professional DAW work ?

On Dec 28, 9:01 pm, Moshe Goldfarb <bricknst...@xxxxxxxxx> wrote:

My biggest complaint is the device section of it.
Hw:0,1, vs dev/dsp(x) etc (can't exactly remember the terms, but it's
the drop down for your sound card outputs).

I had to keep playing with the thing in qjackctrl until it worked.

I simply don't have to get involved with that stuff at that level with
Windows.

Sure. And that's for a very simple reason. Windows doesn't offer you
anything remotely the choices that ALSA's device name scheme does.

First of all, lets dispense with "/dev/dsp.." - this is just a
hangover from the past that you've unfortunately been infected with.
Its not relevant, and even if it still actually works on some Linux
systems (it does), you should forget this as quickly as you've
forgotten anything you ever knew from DOS 3.0.

Secondly, ALSA's names are there for a reason, and that is to enable
the user to specify precisely how they want to access the audio
interface, and when necessary, which part of it they want to access.
Just about every application will work if you use "default" as the
device name, and any application that doesn't is broken. However, that
doesn't make "default" the best choice for everything. Lets take a
look and see why.

RME devices accept only 24-in-32 bit sample format in non-interleaved
layouts (recent RME devices support float format too). Thus, if you
have a 16 bit audio file and you attempt to configure the RME hardware
for 16 bit output, your attempt will fail. However, if you had opened
the "default" device, it would work, no matter what format you asked
for. That is because the "default" device (unless reconfigured by the
user) represents a "pseudo device" that will take care of all that
format stuff for the application/user, no questions asked. Of course,
you don't get a lot of of control over precisely what it does, but it
will ensure that pretty much no matter what format you ask the device
to be configured for, it will work, and your audio will play.

For many applications, particularly desktop/consumer media
applications, this is just what is desired. They have some audio data,
they want to play it, they don't want to know anything (or at least,
not much) about the details of interacting with an audio device. So
applications in this class should generally just default to use
"default" as the device they use in the absence of other information.
This is increasingly redundant as PulseAudio becomes the primary
desktop/consumer audio layer on Linux, but lets not concern ourselves
with that here.

However, for pro-audio applications, this is not true. This class of
applications (generally) does not want some random and possibly low
quality SRC intervening between it and the hardware. It doesn't want
extra latency added to the signal path. It wants to be as close to the
hardware as possible. So this class of applications will want to
interact with the "hw:N" device, which is an access point that is
strictly and absolutely limited to the capabilities of the hardware,
but also guaranteed to be as "close" the hardware as possible. To
return to the RME example, you cannot configure this device for 16 bit
samples, or for interleaved samples, and you cannot request some
subset of the available channels - the hardware itself doesn't offer
any of these capabilities, and thus neither does the "hw:N" device.

There are some half-way houses here. You can define a device, for
example, that corresponds to only the first 4 of a device's N
channels, but still requires the hardware-level sample format to be
used.

Many consumer audio interfaces come with several different sample
clocks on them (e.g. a device with 5 analog outs and an optical S/PDIF
that isn't synced with the other 5). ALSA's "hw:N" names don't try to
pretend that these are part of the same device, so you can refer to,
for example, "hw:0,0" which might be a 5 channel analog output path on
the first soundcard, and "hw:0,1" which might be a stereo digital path
on the same soundcard. I will admit that its not clear to me that this
design (separating devices by clock) is very consumer friendly, but it
is more honest that simply inserting SRC in there somewhere to hide
the fact that the devices are really unsynced.

If you use a pro-audio interface, then this sort of thing really
doesn't apply, since all channels are on the same clock. Therefore, if
you want to use JACK with the N-th soundcard in your machine (counting
from zero like all good programmers do), then the correct device name
to use is "hw:N".


.

Relevant Pages

  • Re: Is Linux A Feasible Platofrm For Professional DAW work ?
    ... RME devices accept only 24-in-32 bit sample format in non-interleaved ... have a 16 bit audio file and you attempt to configure the RME hardware ... quality SRC intervening between it and the hardware. ... I have a Personal configuration that enables only four Mic/Line inputs, one headphone, ...
    (rec.audio.pro)
  • Re: Moving From ProTools to Linux? Good or bad?
    ... I find that it's much easier to explain how audio routing works when people know the fundamentals. ... In hardware I always send them to the block diagram, and if necessary, coach them in reading it. ... I get the hint that Jack has something to do with this, but it's just not clear from what I can see from the JACK GUI. ... Has Linux "found" the sound card? ...
    (rec.audio.pro)
  • Re: got very slow
    ... - Uninstalled unknown/unneeded applications in Add/Remove Programs? ... What hardware do you have? ... What to Know Before You Download and Install Windows XP Service Pack 2 ... You also have hardware on your machine that requires drivers to interface ...
    (microsoft.public.windowsxp.general)
  • Re: OT (Maybe): ERPs
    ... >what hardware, O/S, etc, we run all Intel based systems. ... Boxed off-the-shelf applications, games, ... "TPC benchmarks also differ from other benchmarks in that TPC ... The most frequent transaction consists of entering a new order which, ...
    (comp.lang.cobol)
  • Re: Good bye
    ... And if you expect a 5-year useful life for hardware, ... windows machines are as stable/reliable as anything running Linux. ... full processor, memory, RF, IF, audio, and peripheral drivers on board. ...
    (Fedora)