Floundering in the Audio Maze

I've recently set up a Ubuntu 8.04 system, and I'm just now trying to
get some various audio/midi apps working. By a sort of random walk,
I have them working, but none of my findings make any sense to me.
I'm hoping someone here can straighten me out.

First, the machine is a fairly old i810 motherboard, with an ES1371
sound 'card'. I have an M-Audio USB MIDI unit providing live MIDI-In
from my keyboard (so this is the second MIDI device, as there is an unused
one in the ES1371).

Let's start with fluidsynth. Here's the command line that works:

fluidsynth -a oss -m oss -o midi.oss.device=/dev/midi1 Unison.sf2

I get nice snappy response to input from my piano, so I suppose I should
be happy. However, isn't ALSA supposed to be the standard now? And
my understanding was that OSS is now *emulated* through the ALSA system.
If I try that, though, by replacing "-m oss" in the above with "-m alsa"
(or just leaving it out, to get the default), something approaching a
*one second* latency is added! Hunh...?!

Trying to use ALSA for the MIDI input has completely failed. I've tried
things like "-o midi.alsa.device=hw:1,0,0" (leaving out or modifying
the "-m oss" of course), and never get any response at all.

I'm using the "hw:1,0,0" because I can use it in amidi:

amidi -p hw:1,0,0 -d

shows me the midi I'm sending as I'd expect. However, trying to find out
what ports are actually called in the various schemes is another area
shrouded in mystery (amidi is one of the few ways in I've found...).

Completely baffling me is the note I've just found in the alsa wiki that
says: "Some distributions have the device files like /dev/midi0 and
/dev/midi1. These are not for OSS. They are for tclmidi, which is a
totally different thing.". Gawd...


Then there's Csound (version 5.08). This apparently uses ALSA for MIDI
in, but it *numbers* the ports, so you have to run a trial command to
find out what to specify! In my case it's "2" (no -- not "1"... "Port 0"
is some ALSA "through" port.)

For output it uses PortAudio, and again lists the possibilities:

0: /dev/dsp
1: Ensoniq AudioPCI: ES1371 DAC2/ADC (hw:0,0)
2: Ensoniq AudioPCI: ES1371 DAC1 (hw:0,1)
3: front
4: default
5: dmix

and again if one selects the default or '/dev/dsp', things work. Anything
else than that fails, though, reporting "Invalid sample rate".
I've found no listing of the device characteristics of the above anywhere,
so I don't know if I can set Csound's sample rate to something suitable
or not. And isn't '/dev/dsp' an OSS device? [And why is it "dsp", anyway?
There's no particular Digital Signal Processing going on!]

In particular it would be nice if someone can clarify the relation between
OSS and ALSA (one drives the other, or do they both drive the card
independently?). And though I find commands like amidi and aplay that will
list things, there doesn't seem to be clean translation between their output
and what apps require to indentify a device. Again, pointers would be
appreciated.

I should probably add that I'm only posting this after a couple of days
wading through impenetrable web pages that all seem to assume you know
everything about what they're talking about before they start...
Somebody *really* needs to sort out this mess.

-- Pete --


--
============================================================================
The address in the header is a Spam Bucket -- don't bother replying to it...
(If you do need to email, replace the account name with my true name.)
============================================================================

Look up Jack server and install it, Jack is good **** :)

In article <1226065472.130306@vasbyt.isdsl.net>,
Dogma Discharge <melco@red.co.jp> wrote:[color=blue]
>Look up Jack server and install it, Jack is good **** :)[/color]

And add more confusion to the current mess? Not a chance...
I need to understand the current mechanisms first. Later,
certainly -- it's a useful idea, but it's unlikely to fix
that one-second latency with ALSA! I need to know the source
of that before anything else.
-- Pete --


--
============================================================================
The address in the header is a Spam Bucket -- don't bother replying to it...
(If you do need to email, replace the account name with my true name.)
============================================================================

On Fri, 07 Nov 2008 12:41:43 -0600, Pete wrote:
[color=blue]
> but it's unlikely to fix that one-second latency
> with ALSA! I need to know the source of that
> before anything else.
> -- Pete --[/color]

The source of that is that you're not using jack.

I missed the thread of origins, but IME if you're running artsd or esd and
such, it adds a layer between you and your soundcard. Complete with all
of the tell bob to tell steve delays.

Pete <neverland@goodeveca.net> wrote:
[color=blue]
> However, isn't ALSA supposed to be the standard now? And
> my understanding was that OSS is now *emulated* through the ALSA system.[/color]

The new Open Sound System is up to date and is now available under an
open source general public licence, and it works with Linux.
Unfortunately, it is not being included with mainstream kernels as of
yet, but hopefully it will be an option in future.

You can download and compile this manually. It is not difficult.

[url]http://www.4front-tech.com/developer/sources/stable/gpl/[/url]

Regards,

Mark.

--
Mark Hobley
Linux User: #370818 [url]http://markhobley.yi.org/[/url]

When I started this journey a week ago, I assume that ALSA would be
(at least reasonably) mature. I'm now more inclined to replace the 't'
in that word with an 'n'...

Hopefully I've calmed down enough to post, but don't expect a particularly
civil one.

In article <-OydnWkZM__g4I7UnZ2dnUVZ_rydnZ2d@lmi.net>,
<neverland@GOODEVEca.net> I wrote:[color=blue]
>
>I've recently set up a Ubuntu 8.04 system, and I'm just now trying to
>get some various audio/midi apps working. By a sort of random walk,
>I have them working, but none of my findings make any sense to me.
>I'm hoping someone here can straighten me out.[/color]

Didn't get any helpful responses, so I plugged onward on my own, and at
least found the sources of the problems. The solutions not so much.
[color=blue]
>
>Let's start with fluidsynth. [.....][/color]
(Haven't even got to working on Csound, yet.)[color=blue]
>[/color]
Dealing with the MIDI side first --[color=blue]
>Trying to use ALSA for the MIDI input has completely failed. I've tried
>things like "-o midi.alsa.device=hw:1,0,0" (leaving out or modifying
>the "-m oss" of course), and never get any response at all.[/color]

I found that the default with no '-m' protocol specified is 'alsa_seq',
which is not much use to me, but the '--help' option says:

"-m, --midi-driver=[label]
The name of the midi driver to use [oss,alsa,alsa_seq,...]"

so I added '-m alsa' to the command line. Still nothing.

As a final resort I dig into the source code, and find that the keyword
is *not* in fact 'alsa', but 'alsa_raw'...!! I double-checked all the
documentation I could find, and this is not mentioned anywhere!

Anyhow, the MIDI side now works.


Trying to get some clue about the gigantic output latency, I finally
stumbled across the 'fluid-dev' mailing list archives, where there was
a thread that seemed to bear some relation. Somewhere in the middle of
that, someone said: "Please do
cat /proc/asound/card0/pcm0p/sub0/hw_params"

Oh -- gee -- why didn't I think of that.... (:-/) I had, in fact, explored
the /proc/asound tree quite a bit but had little idea what I was looking
for. I wouldn't have seen anything in that pseudofile anyway, as it only
says "closed" unless an app is actually running.

I did that anyway, with fluidsynth running, and sure enough the buffer
size is giant -- hence the latency. I checked running aplay instead of
fluidsynth, and the buffer is similarly sized, but of course you don't
notice any latency with no real-time input.

I now find that if I use almost anything else than 'default' for the
ALSA device (like 'plughw:0,0' for instance) the buffer is nice and
small, and there's negligible latency, just like the OSS simulation
(which again has a small buffer).

So in theory, I should be able to reconfigure ALSA so that the default
device is suitable for real-time play. However, I've not been able to
find out how or where the default is currently set, let alone how to change
anything! The alsa.conf structure is quite impenetrable, even when I
found some docs.

I tried a minimal '.asoundrc', thinking I could start by making my
second (USB) MIDI the default. It looked like this:

midi.default {
hw:1,0,0
}

Don't know if that affected the midi... because it promptly killed the
'plughw' device!! That's where I give up.

I'll make things work for now just with a local script that has the
long fluidsynth command-line options. Not the best solution, though.

-- Pete --

--
============================================================================
The address in the header is a Spam Bucket -- don't bother replying to it...
(If you do need to email, replace the account name with my true name.)
============================================================================

In article <iemgu5-q5g.ln1@neptune.markhobley.yi.org>,
Mark Hobley <markhobley@hotpop.donottypethisbit.com> wrote:[color=blue]
>Pete <neverland@goodeveca.net> wrote:[color=green]
>> However, isn't ALSA supposed to be the standard now? And
>> my understanding was that OSS is now *emulated* through the ALSA system.[/color]
>
>The new Open Sound System is up to date and is now available under an
>open source general public licence, and it works with Linux.
>Unfortunately, it is not being included with mainstream kernels as of
>yet, but hopefully it will be an option in future.
>[/color]
Yep -- I noticed this in my trawling of the web for some clues to
my problems. I now well see your point! (:-))

As OSS seems to be simulated quite well by ALSA, there's no immediate
need, but I'll keep it in mind.

-- Pete --


--
============================================================================
The address in the header is a Spam Bucket -- don't bother replying to it...
(If you do need to email, replace the account name with my true name.)
============================================================================