Floundering in the Audio Maze - Ubuntu

This is a discussion on Floundering in the Audio Maze - Ubuntu ; 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. ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: Floundering in the Audio Maze

  1. 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.)
    ================================================== ==========================

  2. Re: Floundering in the Audio Maze

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




  3. Re: Floundering in the Audio Maze

    In article <1226065472.130306@vasbyt.isdsl.net>,
    Dogma Discharge wrote:
    >Look up Jack server and install it, Jack is good ****


    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.)
    ================================================== ==========================

  4. Re: Floundering in the Audio Maze

    On Fri, 07 Nov 2008 12:41:43 -0600, Pete wrote:

    > 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 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.

  5. Re: Floundering in the Audio Maze

    Pete wrote:

    > However, isn't ALSA supposed to be the standard now? And
    > my understanding was that OSS is now *emulated* through the ALSA system.


    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.

    http://www.4front-tech.com/developer...es/stable/gpl/

    Regards,

    Mark.

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


  6. Re: Floundering in the Audio Maze

    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>,
    I wrote:
    >
    >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.


    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.

    >
    >Let's start with fluidsynth. [.....]

    (Haven't even got to working on Csound, yet.)
    >

    Dealing with the MIDI side first --
    >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 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.)
    ================================================== ==========================

  7. Re: Floundering in the Audio Maze

    In article ,
    Mark Hobley wrote:
    >Pete wrote:
    >> However, isn't ALSA supposed to be the standard now? And
    >> my understanding was that OSS is now *emulated* through the ALSA system.

    >
    >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.
    >

    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.)
    ================================================== ==========================

+ Reply to Thread