RME9632 Precise Pointer option problem (attn Thomas Charbonnel)

RME9632 Precise Pointer option problem (attn Thomas Charbonnel)

[Ed Wildgoose]

Hi folks,

I haven't been able to get in touch with Thomas with this question, but 
perhaps someone here can help (or perhaps he will see it?)

With this driver the free space call returns only an approximate value, 
however, the "precise pointer" module option returns apparently garbage 
(and there are notes in the source to say this).  Looking at the code 
it's just returning the value from a register, so it's hard to see that 
the driver is doing anything bad.

Does anyone have any insight on whether it's possible to get a good 
value for free space in the buffers?  From a design point of view is it 
sensible to add some kind of fixup which counts ticks to estimate free 
space in the buffers at the driver level, or should stuff like that 
exist only at userspace level, probably in the app?  I realise that we 
can't do this perfectly, but it occurs to me that we can probably remain 
quite accurate estimating the current point location based on counting 
ticks since we started and noting when we add new data, etc.

Any thoughts?

Ed W


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php

Re: RME9632 Precise Pointer option problem (attn Thomas Charbonnel)

[Paul Davis]

>With this driver the free space call returns only an approximate value, 
>however, the "precise pointer" module option returns apparently garbage 
>(and there are notes in the source to say this).  Looking at the code 
>it's just returning the value from a register, so it's hard to see that 
>the driver is doing anything bad.

correct. this is why this option is an option. its not on by default.

>Does anyone have any insight on whether it's possible to get a good 
>value for free space in the buffers?  From a design point of view is it 

its not. you have to keep in mind that RME designed this hardware
around the ASIO model, in which the h/w ptr position is  essentially
irrelevant. consequently, the way in which the ptr is updated is not
particularly reliable.

>quite accurate estimating the current point location based on counting 
>ticks since we started and noting when we add new data, etc.

you should probably first explain why you want to do this. as i
mentioned, the h/w design is really centered on straightforward double
buffering - the application works on one "buffer" and the hardware
works on the other. 

when you add data to the buffer makes no difference to the location of
the hw ptr, btw.

--p


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php

Re: RME9632 Precise Pointer option problem (attn Thomas Charbonnel)

[Manuel Jander]

Hi,

On Mon, 2004-09-27 at 05:20, Ed Wildgoose wrote:
> Hi folks,
> 
> I haven't been able to get in touch with Thomas with this question, but 
> perhaps someone here can help (or perhaps he will see it?)
> 
> With this driver the free space call returns only an approximate value, 
> however, the "precise pointer" module option returns apparently garbage 
> (and there are notes in the source to say this).  Looking at the code 
> it's just returning the value from a register, so it's hard to see that 
> the driver is doing anything bad.

This would not be the first soundcard that needs some conditions to be
met, in order to have a valid value on such kind of register. There
maybe some flags that indicate that the value is correct, or you need to
flag eplicitly that you want to read it. Hopefuly you have the specs, if
not, pass the WDM driver through IDA pro and you probably know what i
mean :). Or maybe a previous I/O operation, register access or whatever
keeps the card busy ? There are many things that could be wrong (check
timing issues).

If it turns out to be a hardware design problem, you could also use the
trustable "not accurate pointer" value to estimate if the "precise
pointer" is on crack or not, and return the most apropriate value. a few
comparison should not represent a considerable amount of overhead, and
you would get a sort of a combination of both "options".

> Does anyone have any insight on whether it's possible to get a good 
> value for free space in the buffers?  From a design point of view is it 
> sensible to add some kind of fixup which counts ticks to estimate free 
> space in the buffers at the driver level, or should stuff like that 
> exist only at userspace level, probably in the app?  I realise that we 
> can't do this perfectly, but it occurs to me that we can probably remain 
> quite accurate estimating the current point location based on counting 
> ticks since we started and noting when we add new data, etc.

Hmm. What about mmap mode ? AFAIK, the idea is that you should not need
to bother about the buffer internals of ALSA. You should just write and
read data. 

Best Regards




-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php

Re: RME9632 Precise Pointer option problem (attn Thomas Charbonnel)

[Ed Wildgoose]

>its not. you have to keep in mind that RME designed this hardware
>around the ASIO model, in which the h/w ptr position is  essentially
>irrelevant. consequently, the way in which the ptr is updated is not
>particularly reliable.
>  
>

Agreed.  Seems to be that way.  Just wondering if someone has some specs 
for the card and perhaps it can be made better...?


>>quite accurate estimating the current point location based on counting 
>>ticks since we started and noting when we add new data, etc.
>>    
>>
>
>you should probably first explain why you want to do this. as i
>mentioned, the h/w design is really centered on straightforward double
>buffering - the application works on one "buffer" and the hardware
>works on the other. 
>
>when you add data to the buffer makes no difference to the location of
>the hw ptr, btw.
>  
>

Many video players clock themselves to the video stream to decide 
exactly when to display the next video frame.  This is not so silly 
because we can be fairly sure the audio clock and system clock will 
diverge through time, so clocking video to audio is the best way to keep 
the in sync (without exotic altenatives).

Unfortunately you should be able to clearly see that if the audio clock 
can only be observed to the nearest full buffer then we are going to get 
some pretty visible jitter even with 1024 sample buffers (which is 
exactly what I see on screen).  Working around this is non-trivial 
really, yeah sure you can use your own clock, but it's still non-trivial 
to recover the audio clock bearing in mind that you only get infrequent 
glipses of it, and even then only the clock is quantised to the size of 
the audio buffer (ie large). 

My idea was that either in every application (tedious), or perhaps at 
the driver level: everytime we are woken up to check the card then we 
can have a look at how full the buffers are (eg when we add data is a 
good time).  At the point that we notice the buffers move from two full 
to one full we can assume that our accurate pointer must have crossed 
the magic boundary and we can determine a bound on the audio clock.  In 
the meantime we take our clock estimate and offset it based on the 
system clock ticks.

Over time (eg several mins) we can probably also obtain a reasonable 
estimate of the audio clock offset compared with the sys clock - this 
might be useful to refine the estimation even further.

Would a patch to do something like this in the driver be accepted (ie 
make the accurate pointer option do this estimation process instead)?  
Adding to each application has potential, but is obviously a pain to do 
it for Xine, mplayer, Ogle, etc, etc)

Does this make sense?

Ed W



-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php

Re: RME9632 Precise Pointer option problem (attn Thomas Charbonnel)

[Paul Davis]

>This would not be the first soundcard that needs some conditions to be
>met, in order to have a valid value on such kind of register. There
>maybe some flags that indicate that the value is correct, or you need to
>flag eplicitly that you want to read it. Hopefuly you have the specs, if
>not, pass the WDM driver through IDA pro and you probably know what i
>mean :). Or maybe a previous I/O operation, register access or whatever
>keeps the card busy ? There are many things that could be wrong (check
>timing issues).

AFAIK, there is no WDM driver, just ASIO, and ASIO doesn't require an
accurate hw ptr.



-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php