Problem with RME 9632 and Plug

Problem with RME 9632 and Plug

[Ed Wildgoose]

I have had a long standing issue with mplayer not working with my RME 
9632.  I have at last finally tracked down part of the problem...

It seems that the RME 9632 in conjunction with the plug device will only 
accept a value of 2 fragments/periods when using the 
"snd_pcm_hw_params_set_periods" call (and the 
"snd_pcm_hw_params_set_periods_near" call sets 2 fragments no matter 
what you ask for).  ....In my case this is causing problems for mplayer 
because this gives too small a buffer, but that's a moot point really...

Can someone please help me debug this further - I'm using Alsa as in the 
2.6.7-mm3 kernel (1.0.5?), but the situation has been like this for a 
while so I don't think exact version numbers are the problem.

Other useful info is that I have written other apps using RtAudio, which 
accesses the hardware layer directly, and although I don't think I 
double checked that I was getting what I asked for, I think I was using 
huge buffers up to 8 or 16 periods.  The point being that direct access 
looks OK, and so this might point to an interaction between Plug and the 
9632 driver?

On the otherhand, mplayer doesn't work for me via the OSS emulation 
either, but the code there doesn't even try to change the frag size, it 
only accepts the default (which is again this small 2 frag buffer).

Any ideas on where to probe next.  I don't really know my way around the 
alsa sources.

Thanks for any help

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

Re: Problem with RME 9632 and Plug

[Paul Davis]

>I have had a long standing issue with mplayer not working with my RME 
>9632.  I have at last finally tracked down part of the problem...
>
>It seems that the RME 9632 in conjunction with the plug device will only 
>accept a value of 2 fragments/periods when using the 

what PCM device name are you using?


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

Re: Problem with RME 9632 and Plug

[Ed Wildgoose]

Paul Davis wrote:

>>I have had a long standing issue with mplayer not working with my RME 
>>9632.  I have at last finally tracked down part of the problem...
>>
>>It seems that the RME 9632 in conjunction with the plug device will only 
>>accept a value of 2 fragments/periods when using the 
>>    
>>
>
>what PCM device name are you using?
>  
>

Relevant bits of /etc/asound.conf

        pcm.rme9632plug {
                type plug
                slave {
                        pcm "rme9632"
                    }
        }
        ctl.rme9632plug {
                type hw
                card 1
        }


And it's this plug device that I am using.

Sorry, should have added this in the first message

Any ideas?

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

Re: Problem with RME 9632 and Plug

[Ed Wildgoose]

Hmm, looking through the 9632 driver code I notice things like:

static snd_pcm_hardware_t snd_hdsp_playback_subinfo =
{
 ..snip ...
        .periods_min =          2,
        .periods_max =          2,


Hmm, oh dear.  Perhaps this driver only allows two periods...?  I could 
have sworn that I was using more than this before though..?  Is there 
any kind of fixup performed at the alsa level which emulates having more 
periods than this...?

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

Re: Problem with RME 9632 and Plug

[Paul Davis]

>Hmm, looking through the 9632 driver code I notice things like:
>
>static snd_pcm_hardware_t snd_hdsp_playback_subinfo =
>{
> ..snip ...
>        .periods_min =          2,
>        .periods_max =          2,
>
>
>Hmm, oh dear.  Perhaps this driver only allows two periods...?  I could 
>have sworn that I was using more than this before though..?  Is there 
>any kind of fixup performed at the alsa level which emulates having more 
>periods than this...?

just test "plughw:0" assuming the 9632 is your initial card, or
"plughw:N" for others.

yes, the "hw" device requires 2 and only 2 periods. its a h/w design.

--p




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

Re: Problem with RME 9632 and Plug

[Ed Wildgoose]

>yes, the "hw" device requires 2 and only 2 periods. its a h/w design.
>  
>

Bugger.  Well, that's the issue then...

Mplayer assumes something like a small buffer size, and 8 
buffers/fragments.  When it meets the 9632 it obviously ends up with a 
smaller buffer, and hence latency, than the frequency it services the 
audio thread.

I have done some work on the audio output layer of mplayer to do a 
little bit of heuristics to increase the period size if it finds that 
the number of fragments are low.  Initial testing looks like this will 
do it.

However, quick question.  Is it possible to create a virtual device 
which will effectively change the default for period size if the app 
doesn't specifically ask for something different (some asound.conf 
magic?).  Also is it possible to influence the defaults for the OSS 
emulation...?

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

Re: Problem with RME 9632 and Plug

[Paul Davis]

>However, quick question.  Is it possible to create a virtual device 
>which will effectively change the default for period size if the app 
>doesn't specifically ask for something different (some asound.conf 
>magic?).  

as i mentioned, try using the pcm device name "plughw:N" where N
appropriate. 

	   Also is it possible to influence the defaults for the OSS 
>emulation...?

yes. but there are at two ways to do it. if mplayer or whatever has
ALSA support, better to get that working.

--p


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

Re: Problem with RME 9632 and Plug

[Jaroslav Kysela]

On Tue, 3 Aug 2004, Paul Davis wrote:

> >However, quick question.  Is it possible to create a virtual device 
> >which will effectively change the default for period size if the app 
> >doesn't specifically ask for something different (some asound.conf 
> >magic?).  
> 
> as i mentioned, try using the pcm device name "plughw:N" where N
> appropriate. 

It won't help. We don't convert count of periods in the plug plugin.
The only one solution is that the application will start using
an external timing source for PCM (see set/get_tick_time functions)
- or another timer available for applications - in this case when 
hardware has this constraint.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs


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

Re: Problem with RME 9632 and Plug

[Ed Wildgoose]

>>as i mentioned, try using the pcm device name "plughw:N" where N
>>appropriate. 
>>    
>>
>
>It won't help. We don't convert count of periods in the plug plugin.
>The only one solution is that the application will start using
>an external timing source for PCM (see set/get_tick_time functions)
>- or another timer available for applications - in this case when 
>hardware has this constraint.
>  
>

Hi, as you say, no difference using "plughw:N".  Also, the plug device 
doesn't seem to help with the max period size, which on this hardware 
seems to be 2048 samples.

However, 2048 samples looks to be *just* enough to make mplayer work ok, 
but there are still some problems occuring which look like they might be 
driver related.  Main issue seems to be that the 
"snd_pcm_status_get_avail" function only returns space in whole chunk 
size blocks, ie with a 2048 sample long buffer, then I only get results 
of 2048 or 0 (you never see 4096, the driver feels that this is an 
over-run condition, which I guess is fair enough - some of the other 
drivers, eg my RME96 PAD seem to give you that one remaining tick to try 
and fill the buffer again before overflow...).  Same thing happens in 
mmap mode

Is this acceptable though for the driver to do this?  ie only return 
space in whole chunks?

The same thing is happening with: "snd_pcm_status_get_delay".  It only 
returns one of three values.  Clearly this is undesirable because it 
significantly compromises synchronisation.  However, again is it within 
spec for the driver to do this? 

As an aside, I think mplayer has sufficient code in there already to 
handle short buffers, it appears to be just a case that it's not tuned 
for buffers quite this small.  I think it should be possible fix it ok.  
But the AV-sync is still an issue.

Can I also just check correct usage for setting number of periods and 
period size. I can't see it mentioned in the docs, but empirically I 
find that I have to set period size first, then number of periods, and 
once I have asked for a period size then it's not possible to change it 
(alsa just refuses and gives me the size that I first requested).  This 
is a bit of a pain because it obviously makes it hard to ask for small 
buffers with lots of periods, then change your mind and ask for larger 
buffers when you discover that 2 periods is all you have got. 

Thanks for any help

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

Re: Problem with RME 9632 and Plug

[Takashi Iwai]

At Wed, 4 Aug 2004 09:39:08 +0200 (CEST),
Jaroslav wrote:
> 
> On Tue, 3 Aug 2004, Paul Davis wrote:
> 
> > >However, quick question.  Is it possible to create a virtual device 
> > >which will effectively change the default for period size if the app 
> > >doesn't specifically ask for something different (some asound.conf 
> > >magic?).  
> > 
> > as i mentioned, try using the pcm device name "plughw:N" where N
> > appropriate. 
> 
> It won't help. We don't convert count of periods in the plug plugin.
> The only one solution is that the application will start using
> an external timing source for PCM (see set/get_tick_time functions)
> - or another timer available for applications - in this case when 
> hardware has this constraint.

Hmm, basically RME h/w can generate enough fine interrupts with a
small period size, but it can handle only two periods.

If we have an intermediate buffer, any number of periods must be able
to handle (only when the given period size or size/N is supported by
hw)...


Takashi


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

Re: Problem with RME 9632 and Plug

[Ed Wildgoose]

>	   Also is it possible to influence the defaults for the OSS 
>  
>
>>emulation...?
>>    
>>
>
>yes. but there are at two ways to do it. if mplayer or whatever has
>ALSA support, better to get that working.
>  
>

True, but I'm trying to get all my apps running through this card, and 
was just interested to know what my options are for other applications?

Thanks for any tips

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

Re: Problem with RME 9632 and Plug

[Ed Wildgoose]

>>It won't help. We don't convert count of periods in the plug plugin.
>>The only one solution is that the application will start using
>>an external timing source for PCM (see set/get_tick_time functions)
>>- or another timer available for applications - in this case when 
>>hardware has this constraint.
>>    
>>
>
>Hmm, basically RME h/w can generate enough fine interrupts with a
>small period size, but it can handle only two periods.
>
>If we have an intermediate buffer, any number of periods must be able
>to handle (only when the given period size or size/N is supported by
>hw)...
>  
>

Are you implying that this is possible with the code today, or only that 
it's theoretically possible to add code to the plug device to do this?

Clearly the plug device could emulate a larger buffer with more periods 
and then run it's own thread to spool the stuff to the hardware in slow 
time.  However, whether this is desirable is another matter.

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

Re: Problem with RME 9632 and Plug

[Jaroslav Kysela]

On Wed, 4 Aug 2004, Takashi Iwai wrote:

> If we have an intermediate buffer, any number of periods must be able
> to handle (only when the given period size or size/N is supported by
> hw)...

The situation is not quite clear for this hardware like for CS46xx etc., 
because it has already the big ring buffer with max period size - 8192 
frames. So only another timing source is enough.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs


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

Re: Problem with RME 9632 and Plug

[Jaroslav Kysela]

On Wed, 4 Aug 2004, Ed Wildgoose wrote:

> However, 2048 samples looks to be *just* enough to make mplayer work ok, 
> but there are still some problems occuring which look like they might be 
> driver related.  Main issue seems to be that the 
> "snd_pcm_status_get_avail" function only returns space in whole chunk 
> size blocks, ie with a 2048 sample long buffer, then I only get results 
> of 2048 or 0 (you never see 4096, the driver feels that this is an 
> over-run condition, which I guess is fair enough - some of the other 
> drivers, eg my RME96 PAD seem to give you that one remaining tick to try 
> and fill the buffer again before overflow...).  Same thing happens in 
> mmap mode

Set precise_ptr module option for your driver.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs


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

Re: Problem with RME 9632 and Plug

[Ed Wildgoose]

Ed Wildgoose wrote:

>
>>> It won't help. We don't convert count of periods in the plug plugin.
>>> The only one solution is that the application will start using
>>> an external timing source for PCM (see set/get_tick_time functions)
>>> - or another timer available for applications - in this case when 
>>> hardware has this constraint.   
>>
>> Hmm, basically RME h/w can generate enough fine interrupts with a
>> small period size, but it can handle only two periods.
>>
>> If we have an intermediate buffer, any number of periods must be able
>> to handle (only when the given period size or size/N is supported by
>> hw)...
>
> Are you implying that this is possible with the code today, or only 
> that it's theoretically possible to add code to the plug device to do 
> this?
>
> Clearly the plug device could emulate a larger buffer with more 
> periods and then run it's own thread to spool the stuff to the 
> hardware in slow time.  However, whether this is desirable is another 
> matter.


Of course this functionality is already in dmix isn't it?  ie DMix will 
emulate a virtual device with arbitrary sized buffers and periods?  Or 
does it just let you select values but require that they correspond to 
those that the hardware is capable of supporting?

I have tried a few quick workarounds to find something which would 
emulate a device with higher latency.  Jack was the obvious one, but 
even there it seems to only show the underlying hardware and hence you 
are back to 2 periods again.

Hacking mplayer is proving a little more tricky... I will take my 
thoughts to the mplayer list, but it looks as though the main decoding 
loop can't quite get down to very low latencies, the process of 
alternating between decoding a video frame, then adding some audio is 
still causing the odd dropout, and presumably this is caused by the 
video decoding phase (more testing needed)

Thanks for any ideas on workarounds

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

Re: Problem with RME 9632 and Plug

[Takashi Iwai]

At Wed, 4 Aug 2004 12:20:14 +0200 (CEST),
Jaroslav wrote:
> 
> On Wed, 4 Aug 2004, Takashi Iwai wrote:
> 
> > If we have an intermediate buffer, any number of periods must be able
> > to handle (only when the given period size or size/N is supported by
> > hw)...
> 
> The situation is not quite clear for this hardware like for CS46xx etc., 
> because it has already the big ring buffer with max period size - 8192 
> frames. So only another timing source is enough.

Well, HDSP needs at least 14 non-interleaved channels, so we'll need
anyway the conversion for normal apps like mplayer.  Then no external
timinig source would be needed.


Takashi


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

Re: Problem with RME 9632 and Plug

[Ed Wildgoose]

Jaroslav Kysela wrote:

>On Wed, 4 Aug 2004, Takashi Iwai wrote:
>
>  
>
>>If we have an intermediate buffer, any number of periods must be able
>>to handle (only when the given period size or size/N is supported by
>>hw)...
>>    
>>
>
>The situation is not quite clear for this hardware like for CS46xx etc., 
>because it has already the big ring buffer with max period size - 8192 
>frames. So only another timing source is enough.
>  
>

Ahh, yes, I see now.  The max period size SHOULD be 8192.  For some 
reason when I request anything larger than 2048, I only get 2048...  I 
have tried asking for exactly 8192, and "_near" 8192 with the same results.

I will try giving the machine a reboot in case something has grabbed the 
card and it's ended up in a funny state which might be causing this.  
However, I can currently happily choose 512, 1024, and 2048 period 
sizes, but nothing larger.

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

Re: Problem with RME 9632 and Plug

[Jaroslav Kysela]

On Wed, 4 Aug 2004, Ed Wildgoose wrote:

> Ahh, yes, I see now.  The max period size SHOULD be 8192.  For some 
> reason when I request anything larger than 2048, I only get 2048...  I 
> have tried asking for exactly 8192, and "_near" 8192 with the same results.
> 
> I will try giving the machine a reboot in case something has grabbed the 
> card and it's ended up in a funny state which might be causing this.  
> However, I can currently happily choose 512, 1024, and 2048 period 
> sizes, but nothing larger.

It's better to send us a dump from /proc/asound/card0/pcm0p/sub0/* files
to verify the correct values. But I guess that resampling might be 
involved, so the final frame count is smaller from the application view.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs


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

Re: Problem with RME 9632 and Plug

[Jaroslav Kysela]

On Wed, 4 Aug 2004, Takashi Iwai wrote:

> Well, HDSP needs at least 14 non-interleaved channels, so we'll need
> anyway the conversion for normal apps like mplayer.  Then no external
> timinig source would be needed.

I don't undestand this. As far as I know, RME cards have 64kB ring buffer 
for all voices and the two periods constraint is for all voices. Thus 
there is no correlation between the used channel count and period size.
The timing is same.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs


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

Re: Problem with RME 9632 and Plug

[Takashi Iwai]

At Wed, 4 Aug 2004 12:56:28 +0200 (CEST),
Jaroslav wrote:
> 
> On Wed, 4 Aug 2004, Takashi Iwai wrote:
> 
> > Well, HDSP needs at least 14 non-interleaved channels, so we'll need
> > anyway the conversion for normal apps like mplayer.  Then no external
> > timinig source would be needed.
> 
> I don't undestand this. As far as I know, RME cards have 64kB ring buffer 
> for all voices and the two periods constraint is for all voices. Thus 
> there is no correlation between the used channel count and period size.
> The timing is same.

I mean, we need anyway convert the format and the interleave ->
non-interleave in this case.  In comparison with this, introducing an
intermedate buffer with an arbitrary size doesn't influence on the
performance so much.

I don't think to do this in plug as default.  But it would be nice to
have this layer for devices with the limited periods and/or buffer
size (of course only if the extra data transfer doesn't matter).


Takashi


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

Re: Problem with RME 9632 and Plug

[Ed Wildgoose]

Jaroslav Kysela wrote:

>On Wed, 4 Aug 2004, Ed Wildgoose wrote:
>
>  
>
>>However, 2048 samples looks to be *just* enough to make mplayer work ok, 
>>but there are still some problems occuring which look like they might be 
>>driver related.  Main issue seems to be that the 
>>"snd_pcm_status_get_avail" function only returns space in whole chunk 
>>size blocks, ie with a 2048 sample long buffer, then I only get results 
>>of 2048 or 0 (you never see 4096, the driver feels that this is an 
>>over-run condition, which I guess is fair enough - some of the other 
>>drivers, eg my RME96 PAD seem to give you that one remaining tick to try 
>>and fill the buffer again before overflow...).  Same thing happens in 
>>mmap mode
>>    
>>
>
>Set precise_ptr module option for your driver.
>  
>

Hmm, well this now seems to give a more accurate space available as you 
say, but it now causes buffer overruns constantly....

I can see that the docs say that this option doesnt work well of 
course..  However, something looks broken here:

Here is some debug I added from the app.  This is typical - notice how 
despite the fact that we can see that we are being called very regularly 
the final call before the overflow is quite reasonable, and yet alsa 
says that an overflow occurred?  Just by eye, there should be no 
overflow here because we would have filled the buffer to the top only a 
few thousand samples before...


alsa-space: free space = 16384, prepared --53/ 50  10% 23%  0.8% 0 0 88%

About to play: 16384 bytes, time since last called: 784.000000
About to play: 3008 bytes, time since last called: 16007.000000
About to play: 3328 bytes, time since last called: 17583.000000
About to play: 3968 bytes, time since last called: 20767.000000
About to play: 5568 bytes, time since last called: 28723.000000
About to play: 0 bytes, time since last called: 13966.000000
alsa-space: xrun of at least 2.831 msecs. resetting stream  0.8% 0 0 87%
alsa-space: free space = 0, xrun --


Any theories on why precise_ptr might be causing this?

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

Re: Problem with RME 9632 and Plug

[Ed Wildgoose]

>>Ahh, yes, I see now.  The max period size SHOULD be 8192.  For some 
>>reason when I request anything larger than 2048, I only get 2048...  I 
>>have tried asking for exactly 8192, and "_near" 8192 with the same results.
>>
>>I will try giving the machine a reboot in case something has grabbed the 
>>card and it's ended up in a funny state which might be causing this.  
>>However, I can currently happily choose 512, 1024, and 2048 period 
>>sizes, but nothing larger.
>>    
>>
>
>It's better to send us a dump from /proc/asound/card0/pcm0p/sub0/* files
>to verify the correct values. But I guess that resampling might be 
>involved, so the final frame count is smaller from the application view.
>  
>

Reboot achieved nothing.

(Did the following while the app was active)

mm MPlayer-1.0pre5 # ls /proc/asound/card1/pcm0p/sub0/*
/proc/asound/card1/pcm0p/sub0/hw_params  
/proc/asound/card1/pcm0p/sub0/info  
/proc/asound/card1/pcm0p/sub0/status  
/proc/asound/card1/pcm0p/sub0/sw_params
mm MPlayer-1.0pre5 # cat /proc/asound/card1/pcm0p/sub0/*
access: MMAP_NONINTERLEAVED
format: S32_LE
subformat: STD
channels: 12
rate: 48000 (48000/1)
period_size: 2048
buffer_size: 4096
tick_time: 1000
card: 1
device: 0
subdevice: 0
stream: PLAYBACK
id: RME Hammerfall HDSP 9632
name: RME Hammerfall HDSP 9632
subname: subdevice #0
class: 0
subclass: 0
subdevices_count: 1
subdevices_avail: 0
state: RUNNING
trigger_time: 1091618462.875884000
tstamp      : 1091618462.918708000
delay       : 3872
avail       : 224
avail_max   : 224
-----
hw_ptr      : 2048
appl_ptr    : 5920
tstamp_mode: NONE
period_step: 1
sleep_min: 0
avail_min: 2048
xfer_align: 2048
start_threshold: 1
stop_threshold: 4096
silence_threshold: 0
silence_size: 0
boundary: 1073741824





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

Re: Problem with RME 9632 and Plug

[Paul Davis]

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.

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.

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.

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.

--p


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

Re: Problem with RME 9632 and Plug

[Ed Wildgoose]

>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

Re: Problem with RME 9632 and Plug

[Paul Davis]

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

you've got things the wrong way around - you get to *ask* for a
specific h/w setup, the driver gets to accept or reject 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), 

yes, it is heuristic. this is a problem caused mostly by the 
range of designs in contemporary audio interfaces. ALSA could hide
this from you by adding buffering in the way Takashi described, but
that would add latency and/or complications. 

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

it is possible to start over with a new h/w parameter setup, but you
will have to reinitiatize the settings structure and start from the top.
otherwise, you're still working with the rest of the values that
you've already set.

>Latest mplayer has jack support via the bio2jack library.

Yeah, but bio2jack is a (working) hack and half. And it doesn't
support lowlatency work properly either, because the thread that
*really* does audio isn't scheduled as part of the JACK graph and
doesn't get SCHED_FIFO status. I see this in xmms all the time when I
do a multiway compile - JACK has no (or almost no) xruns, but the
audio in xmms skips because the "feeder" thread doesn't get scheduled
in time to fill the intermediate buffer.

>#define CONFIG_SND_VERSION "1.0.5"

hmm, should be fine. I am not sure what would be causing that
error. In what order are you trying to set the h/w parameters?

--p


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

Re: Problem with RME 9632 and Plug

[Ed Wildgoose]

Paul Davis wrote:

>>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?
>>    
>>
>
>you've got things the wrong way around - you get to *ask* for a
>specific h/w setup, the driver gets to accept or reject them. 
>  
>

I think we are saying the same thing.

Basically, I set 1024 as the period size first (since this seems a 
reasonable size), then set periods to be "near" 16, however, the driver 
tells me that I can only have 2.  But at this point I can't go back and 
bump up the period size to 8192 or similar.

Actually just to be clear and avoid confusion, if I try on the RME9632 
to set period size to be "near" 8192 right at the start then I just get 
2048.  Very peculiar.


>>Latest mplayer has jack support via the bio2jack library.
>>    
>>
>
>Yeah, but bio2jack is a (working) hack and half. And it doesn't
>support lowlatency work properly either, because the thread that
>*really* does audio isn't scheduled as part of the JACK graph and
>doesn't get SCHED_FIFO status. I see this in xmms all the time when I
>do a multiway compile - JACK has no (or almost no) xruns, but the
>audio in xmms skips because the "feeder" thread doesn't get scheduled
>in time to fill the intermediate buffer.
>  
>

Agree it's a bit of a hack, but I can't see your problem.  If you 
removed the feeder thread, then presumably the problem would still 
remain because fundamentally xmms needs to be realtime as well or else 
it won't decode fast enough to keep up with JACK?

I think that bio2jack has a large buffer, and presumably this in 
conjunction with Jack waking it up regularly via the call back is about 
as good as you can do anyway no?

I will have to look at bio2jack again though - it's been a while since I 
studied it.  I was going to use it as a quick way to add Jack output to 
Mythtv.

Thanks for any pointers on the 8192 issue.

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

Re: Problem with RME 9632 and Plug

[James Courtier-Dutton]

Ed Wildgoose wrote:
> 
> 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).
> 

Why don't you use the alsa api more fully.
You can gather information about min/max period/buffer sizes before 
setting any values.
This is not 100% certain to work, as alsa hardware contraints can be 
extremely complicated if the hardware so desires.

But I do think that the setting of period_size/time, buffer_size/time 
and periods has always been problematic in alsa.

Being able test different period and buffer sizes without having to 
close/open the device would be a useful addition to the alsa api.

Cheers
James


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

Re: Problem with RME 9632 and Plug

[Zsolt Barat]

Paul Davis wrote:

>Yeah, but bio2jack is a (working) hack and half. And it doesn't
>support lowlatency work properly either, because the thread that
>*really* does audio isn't scheduled as part of the JACK graph and
>doesn't get SCHED_FIFO status. I see this in xmms all the time when I
>do a multiway compile - JACK has no (or almost no) xruns, but the
>audio in xmms skips because the "feeder" thread doesn't get scheduled
>in time to fill the intermediate buffer.
>
>  
>
mplayer_g2 will probably change its architecture, so a poll like 
behaviour like jack uses will be possible. developers are still welcome 
to port (write) ao_jack for mplayer_g2 though.
on the other side, adding low latency features to mplayer aren't really 
possible, cause mplayer is designed intentionally as a movie player, so 
while you watching movies you will never get low latency audio. adding 
some low-lat features when it will be used as stand-alone audio app 
could be possible. but there are several audio-only-apps which already 
have full jack and alsa support (alsaplayer) so i don't really see a 
need for blown up low-lat audio support in mplayer.

regards

Zsolt



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

Re: Problem with RME 9632 and Plug

[Zsolt Barat]

Ed Wildgoose wrote:

> Basically, I set 1024 as the period size first (since this seems a 
> reasonable size), then set periods to be "near" 16, however, the 
> driver tells me that I can only have 2.  But at this point I can't go 
> back and bump up the period size to 8192 or similar.
>
> Actually just to be clear and avoid confusion, if I try on the RME9632 
> to set period size to be "near" 8192 right at the start then I just 
> get 2048.  Very peculiar.
>
>
just in case you didn't noticed you already can set different setups for 
some periods (frags) and periodsizes. it would be triggered by the -abs 
option in mplayer. it isn't documented i know.

      switch (ao_data.buffersize)
    {
    case 1:
      alsa_fragcount = 16;
      chunk_size = 512;
        mp_msg(MSGT_AO,MSGL_V,"alsa-init: buffersize set manually to 
8192\n");
        mp_msg(MSGT_AO,MSGL_V,"alsa-init: chunksize set manually to 512\n");
      break;
    case 2:
      alsa_fragcount = 8;
      chunk_size = 1024;
        mp_msg(MSGT_AO,MSGL_V,"alsa-init: buffersize set manually to 
8192\n");
        mp_msg(MSGT_AO,MSGL_V,"alsa-init: chunksize set manually to 
1024\n");
      break;
    case 3:
      alsa_fragcount = 32;
      chunk_size = 512;
        mp_msg(MSGT_AO,MSGL_V,"alsa-init: buffersize set manually to 
16384\n");
        mp_msg(MSGT_AO,MSGL_V,"alsa-init: chunksize set manually to 512\n");
      break;
    case 4:
      alsa_fragcount = 16;
      chunk_size = 1024;
        mp_msg(MSGT_AO,MSGL_V,"alsa-init: buffersize set manually to 
16384\n");
        mp_msg(MSGT_AO,MSGL_V,"alsa-init: chunksize set manually to 
1024\n");
      break;
    default:
      alsa_fragcount = 16;
      if (ao_mmap)
        chunk_size = 512;
      else
        chunk_size = 1024;
      break;
    }
    }

fragcount is periods here and chunksize is periodsize (could be reanamed 
probably).

btw. could you send me your changes you made?

regards

Zsolt




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

Re: Problem with RME 9632 and Plug

[Paul Davis]

>on the other side, adding low latency features to mplayer aren't really 
>possible, cause mplayer is designed intentionally as a movie player, so 

our kids use it for audio, and have done so without me even telling
them it can do that. i suspect they are not alone. some of the skins
make it look very much like an audio app.

>while you watching movies you will never get low latency audio. adding 

not true, but i understand your point.

--p


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