Re: Problem with RME 9632 and Plug

[Ed Wildgoose <lists@wildgooses.com>]

>I humbly suggest that you stop what you're trying to do and shift your
>focus a little. I know that you just want to get MPlayer to work on
>your audio interface, and I understand your frustration. But MPlayer's
>audio layer was clearly written by people who see the audio
>programming world through the same rather simplistic model that OSS
>presented. Note that even by OSS standards, the code is wrong: OSS
>makes it clear that the app *must* be prepared for some of the
>parameters to fail and must adopt a fallback position. MPlayer should
>have more num_periods options than it does - to not do so is simple
>incorrect even for the OSS API.
>  
>

I'm not sure what you are saying here.  I have the source code in front 
of me in an editor, but I physically can't set the options correctly - 
the driver just rejects them?

The issue is the heuristic - I appear to have to try for the period size 
first, then set the number of periods (fails if I do it the other way 
around), however, if I then discover the number of periods * period size 
is lower than I would like, I cant go and adjust these settings (alsa 
returns errors).

The options that mplayer offers seem to be reasonable in my opinion.  
Although I might submit a patch to change the default period size to 2048.

>There are other people in the community who want to see MPlayer
>support JACK. This will require (as I understand it) a bit of a
>redesign of MPlayer to accomodate the callback design that JACK uses.
>MPlayer is still clearly (from the output you added) based on the
>"write-whatever-i-want-whenever-i-want-to" model of audio i/o. This
>just isn't going to work for low(ish) latency work, and it doesn't
>integrate with a callback model particularly easily. When MPlayer
>supports JACK, it won't matter what the audio interface is.
>  
>

Latest mplayer has jack support via the bio2jack library.

You can easily make any app talk to a callback model simply by decoding 
the audio ahead of what you need into a buffer and then leaving a 
seperate thread, or call back to drain this buffer down as it needs to.  
This is the approach bio2jack uses.


>So either fix the audio layer in MPlayer to handle configuration
>failures properly (i.e. trying other values) or help get MPlayer
>working with JACK.
>  
>

That's my point.  Alsa won't let me try other values, not mplayer...  I 
haven't tried Jack with mplayer, but it's my intention to use Jack 
everywhere here to allow some arbitrary FIR filter processing to my 
sound output.

>In the meantime, which version of ALSA are you using? The 8192 issue
>was present in an older version, but was fixed, oh, at least 6 months
>ago.
>  
>

I'm on 2.6.7-mm3 ish. 

mm linux # more include/sound/version.h
/* include/version.h.  Generated by configure.  */
#define CONFIG_SND_VERSION "1.0.5"
#define CONFIG_SND_DATE " (Sun May 30 10:49:40 2004 UTC)"

I could update to 1.0.5a but I gather it's just a minor bug fix?

The 8192 is getting on my nervest though.  I'm sure I had it working 
earlier...?  Any ideas?

Thanks

Ed W


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com