Getting actual sample rate

Getting actual sample rate

[Eric Allamanche]

Hi,

I'm using a digital Hammerfall audio card and was wondering how to 
figure out the sample rate of the ADAT input pcm stream (which can vary 
from 32kHZ to 96kHZ). I tried functions like 
snd_pcm_hw_params_get_rate() but they do not seem to give the right 
answer. Any hints?
BTW, when the input format changes, it would be great to be notified 
about this. Are there any notification handler which could be used for 
this purpose.

Eric



-------------------------------------------------------
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.

Re: Getting actual sample rate

[Paul Davis]

>I'm using a digital Hammerfall audio card and was wondering how to 

which hammerfall? digi9652 or hdsp9652?

>figure out the sample rate of the ADAT input pcm stream (which can vary 
>from 32kHZ to 96kHZ). I tried functions like 
>snd_pcm_hw_params_get_rate() but they do not seem to give the right 
>answer. Any hints?

the ALSA hardware parameter model doesn't include the notion of an
"external rate". 

>BTW, when the input format changes, it would be great to be notified 
>about this. Are there any notification handler which could be used for 
>this purpose.

there is no way to differentiate between an ADAT signal at 32/44.1/48
kHz and a "bit/channel stream format" at 64/88.2/96 kHz. so we can't
tell you that. however, on the hdsp series, the "External Rate"
control (read only) can be used to check the rate. i don't know
off hand whether it can be used for notifications via blocking on
read/poll for the control.




-------------------------------------------------------
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.

Re: Getting actual sample rate

[Martin Langer]

On Tue, Jun 10, 2003 at 12:24:21PM -0400, Paul Davis wrote:
> >I'm using a digital Hammerfall audio card and was wondering how to 
> 
> which hammerfall? digi9652 or hdsp9652?
> 
> >figure out the sample rate of the ADAT input pcm stream (which can vary 
> >from 32kHZ to 96kHZ). I tried functions like 
> >snd_pcm_hw_params_get_rate() but they do not seem to give the right 
> >answer. Any hints?
> 
> the ALSA hardware parameter model doesn't include the notion of an
> "external rate". 
> 
> >BTW, when the input format changes, it would be great to be notified 
> >about this. Are there any notification handler which could be used for 
> >this purpose.
> 
> there is no way to differentiate between an ADAT signal at 32/44.1/48
> kHz and a "bit/channel stream format" at 64/88.2/96 kHz. so we can't
> tell you that. however, on the hdsp series, the "External Rate"
> control (read only) can be used to check the rate. i don't know
> off hand whether it can be used for notifications via blocking on
> read/poll for the control.
> 

Up to now, I thought ADAT was only defined for 44.1 and 48 kHz, but maybe
I'm wrong in this point. Ok, I believe that the hw doesn't use a restriction in
that point. But are there really any devices that can handle all those rates.

(I have asked rme a few month ago, and they told me that ADAT is only defined
for 44.1/48 kHz. But I've only asked them for 32kHz and not for the
double-speed modes, because I'm still living in a rme32 world;-) ) 

Hmm, does this info help in some way?


martin


-------------------------------------------------------
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.

Re: Getting actual sample rate

[Paul Davis]

this is the most important question for now:

>> which hammerfall? digi9652 or hdsp9652?


>Up to now, I thought ADAT was only defined for 44.1 and 48 kHz, but maybe
>I'm wrong in this point. Ok, I believe that the hw doesn't use a restriction i
>n
>that point. But are there really any devices that can handle all those rates.

i should not have included 32kHz in there. however 88.2 and 96kHz are
supported using "channel splitting" where the data is interleaved
across 2 channels. there is no way to tell that it is being done.


-------------------------------------------------------
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.

Re: Getting actual sample rate

[Eric Allamanche]

Thanks for feedback,

Martin Langer wrote:
> On Tue, Jun 10, 2003 at 12:24:21PM -0400, Paul Davis wrote:
> 
>>>I'm using a digital Hammerfall audio card and was wondering how to 
>>
>>which hammerfall? digi9652 or hdsp9652?

I think it's an older digi9652, I have to open the PC to check it out

>>the ALSA hardware parameter model doesn't include the notion of an
>>"external rate". 

Is this is a design flaw? How to tell the input frequency? Need some 
additionnal hardware?

>>there is no way to differentiate between an ADAT signal at 32/44.1/48
>>kHz and a "bit/channel stream format" at 64/88.2/96 kHz. so we can't
>>tell you that. however, on the hdsp series, the "External Rate"
>>control (read only) can be used to check the rate. i don't know
>>off hand whether it can be used for notifications via blocking on
>>read/poll for the control.
>>
> 
> 
> Up to now, I thought ADAT was only defined for 44.1 and 48 kHz, but maybe
> I'm wrong in this point. Ok, I believe that the hw doesn't use a restriction in
> that point. But are there really any devices that can handle all those rates.

I checked it again, ADAT is only defined for 44.1/48 kHz. I mixed it up 
with the Hammerfall specifications in the manual. The supported 
frequencies ranges from 32 to 96kHz (SPDIF mode?)

Eric



-------------------------------------------------------
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.

Re: Getting actual sample rate

[Paul Davis]

>Is this is a design flaw? How to tell the input frequency? Need some 
>additionnal hardware?

the ALSA h/w parameters are things set by an application (and
perhaps later read by the same or a different application). 

what ALSA supports (and the hdsp driver in particular; the digi9652 is
not so good here) is the notion of defining the clock source. if the
clock source is internal, then some h/w (i think this applies to the
digi9652) can't tell you the external rate for the ADAT signal. if the
clock source is external, then you can't set the rate from an
application. of course, you might want to know what it is. in which
case, you have to read the relevant control, which is called "External
Rate" on the hdsp series. unfortunately, an equivalent control does
not exist for the digi9652 series, though it would be easy to write (i
would do it if i wasn't so busy with other projects right now).

i think it would have been good for ALSA to have considered this more
early on; as it is, only a few cards support external clocking, and
the drivers for those cards have had to make it up as they were written.

>I checked it again, ADAT is only defined for 44.1/48 kHz. I mixed it up 
>with the Hammerfall specifications in the manual. The supported 
>frequencies ranges from 32 to 96kHz (SPDIF mode?)

as explained, ADAT can be used up to 96kHz but it halves the number of
available channels.


-------------------------------------------------------
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.

Re: Getting actual sample rate

[Jaroslav Kysela]

On Tue, 10 Jun 2003, Eric Allamanche wrote:

> >>the ALSA hardware parameter model doesn't include the notion of an
> >>"external rate". 
> 
> Is this is a design flaw? How to tell the input frequency? Need some 
> additionnal hardware?

No. It is not. As Paul mentioned, we have universal control for this 
purpose. It can notify the application about rate change independently 
from the PCM layer and multiple applications might react to this state
change.

Also, the official behaviour for external rate is: compare the external
rate by rate given by application; when the driver handles new samples and
and stream trigger time; if rate does not match, fail with error. This
behaviour assures that application does not get samples with wrong rate.

						Jaroslav

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



-------------------------------------------------------
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.

Re: Getting actual sample rate

[Martin Langer]

On Tue, Jun 10, 2003 at 01:56:55PM -0400, Paul Davis wrote:
> >Is this is a design flaw? How to tell the input frequency? Need some 
> >additionnal hardware?
> 
> the ALSA h/w parameters are things set by an application (and
> perhaps later read by the same or a different application). 
> 
> what ALSA supports (and the hdsp driver in particular; the digi9652 is
> not so good here) is the notion of defining the clock source. if the
> clock source is internal, then some h/w (i think this applies to the
> digi9652) can't tell you the external rate for the ADAT signal. if the
> clock source is external, then you can't set the rate from an
> application. of course, you might want to know what it is. in which
> case, you have to read the relevant control, which is called "External
> Rate" on the hdsp series. unfortunately, an equivalent control does
> not exist for the digi9652 series, though it would be easy to write (i
> would do it if i wasn't so busy with other projects right now).
> 
> i think it would have been good for ALSA to have considered this more
> early on; as it is, only a few cards support external clocking, and
> the drivers for those cards have had to make it up as they were written.
> 

Maybe we can add some rme9652 switches to rmedigicontrol!?
But I need at first the output of "amixer contents".
.. and what is "cat /proc/asound/card0/id"? Is it "Digi9652"?

BTW: ... I'm still searching for rme96 users who can check rmedigicontrol
version 0.3.5a together with a patched rme96 driver. 
Hey rme96 crowd! Does it work? 

See http://www.langerland.de/rme32/control.html


martin


-------------------------------------------------------
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.

Re: Getting actual sample rate

[Paul Davis]

>Maybe we can add some rme9652 switches to rmedigicontrol!?

thomas (charbonnel) already has written a version of rme's digicheck
for the digi9652 and hdsp cards. i am not sure what its status is, but
i saw it running at LAD/ZKM.



-------------------------------------------------------
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.

Re: Getting actual sample rate

[David E. Storey]

[-- Attachment #1: Type: text/plain, Size: 490 bytes --]

hey, uh... is there something like this for the HDSP? I was going to
write something, but if someone already has, I'd rather not re-invent
the wheel... otherwise, I'll get a crackin'!

d!

On Tue, 2003-06-10 at 15:35, Paul Davis wrote:
> >Maybe we can add some rme9652 switches to rmedigicontrol!?
> 
> thomas (charbonnel) already has written a version of rme's digicheck
> for the digi9652 and hdsp cards. i am not sure what its status is, but
> i saw it running at LAD/ZKM.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Getting actual sample rate

[Paul Davis]

>hey, uh... is there something like this for the HDSP? I was going to
>write something, but if someone already has, I'd rather not re-invent
>the wheel... otherwise, I'll get a crackin'!

thomas's code works on the hdsp i think, and is easily adapted to the
digi9652. he also has written totalmix for linux. i don't know why he
hasn't released it yet. thomas?


-------------------------------------------------------
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.

Re: Getting actual sample rate

[David E. Storey]

[-- Attachment #1: Type: text/plain, Size: 1159 bytes --]

On Tue, 2003-06-10 at 16:26, Paul Davis wrote:
> thomas's code works on the hdsp i think, and is easily adapted to the
> digi9652. he also has written totalmix for linux. i don't know why he
> hasn't released it yet. thomas?

that would be handy. I've successfully used ALSA and an HDSP to do in
ear monitor mixing for a band I run sound for. But I'm only guessing at:

a) converting "fader" levels to something logarithmic like db
b) converting fader levels to the 0-65535 exponential scale that the
hdsp uses, and
c) converting the 0-65535 back into fader levels

I've got some questions into one of the guys at RME that developed this
thing to see how they do it. Any insight would be excellent as I'm about
to plop down some cash on an ADI 8 Pro to expand out to 16 channels
through my HDSP... <wink,wink;nudge,nudge>

I've also successfully captured peak and RMS levels via the
snd_hwdep_ioctl() interface, but I'm a) unsure of how to convert that to
something graphical and b) how often to call the ioctl to display. (I'm
assuming that it's only as often as I want to refresh the levels which I
can easily do with a timer.)

d!

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Getting actual sample rate

[Paul Davis]

>that would be handy. I've successfully used ALSA and an HDSP to do in
>ear monitor mixing for a band I run sound for. But I'm only guessing at:
>
>a) converting "fader" levels to something logarithmic like db
>b) converting fader levels to the 0-65535 exponential scale that the
>hdsp uses, and
>c) converting the 0-65535 back into fader levels
>
>I've got some questions into one of the guys at RME that developed this
>thing to see how they do it. Any insight would be excellent as I'm about

i believe thomas has figured this all out. it would be great if he
could comment on what is going on with his totalmix implementation,
especially if you have time to work on it. 

>I've also successfully captured peak and RMS levels via the
>snd_hwdep_ioctl() interface, but I'm a) unsure of how to convert that to
>something graphical and b) how often to call the ioctl to display. (I'm
>assuming that it's only as often as I want to refresh the levels which I
>can easily do with a timer.)

remember not to bother with much more than about 70Hz, since your
monitor doesn't do much than that. i usually do meter updates at
either 50 or 100 times a second.

thomas' code contains the results of the communications i had with RME
about this. it was unclear if the conversions should go into the
driver or not.

--p


-------------------------------------------------------
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.

Re: Getting actual sample rate

[tom burkart]

Today, Paul Davis wrote:

> thomas' code contains the results of the communications i had with RME
> about this. it was unclear if the conversions should go into the
> driver or not.
I had a similar issue with a driver that is about to be published and I
decided that userspace can do that one...

tom.



-------------------------------------------------------
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.

Power saving mode

[Giuliano Pochini]

My card which can enter a low power state. It turns
off some components but it leaves the PCI bus interface
active. To bring the card back to life it has to be
reinitialized from scratch. What "D" state is it ?  PCI
power management papers say that already in D1 state
i/o space is disabled. I'm a bit confused... I can't
find any doc about D0.5  :)


Bye.



-------------------------------------------------------
This SF.NET email is sponsored by: eBay
Great deals on office technology -- on eBay now! Click here:
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5

Re: Getting actual sample rate

[David E. Storey]

[-- Attachment #1: Type: text/plain, Size: 602 bytes --]

Anyone care to shed the light on the math for what totalmix does
regarding fader-to-mixer, fader-to-db and mixer-to-fader values? What I
have works, but it's UGLY. (well just the constants... I like things to
be simple.)

d!

On Wed, 2003-06-11 at 00:48, tom burkart wrote:
> Today, Paul Davis wrote:
> 
> > thomas' code contains the results of the communications i had with RME
> > about this. it was unclear if the conversions should go into the
> > driver or not.
> I had a similar issue with a driver that is about to be published and I
> decided that userspace can do that one...


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Getting actual sample rate

[Paul Davis]

>Anyone care to shed the light on the math for what totalmix does
>regarding fader-to-mixer, fader-to-db and mixer-to-fader values? What I
>have works, but it's UGLY. (well just the constants... I like things to
>be simple.)

you could use the settings in ardour, which has relatively
sophisticated non-linear, volumetric slider function. these map
between a 0..1 fractional position and a gain coefficient.

static inline double 
gain_to_slider_position (ARDOUR::gain_t g)
{
	if (g == 0) return 0;
	return pow((6.0*log(g)/log(2.0)+192.0)/198.0, 8.0);

}

static inline ARDOUR::gain_t 
slider_position_to_gain (double pos)
{
	/* XXX Marcus writes: this doesn't seem right to me. but i don't have a better answer ... */
	return pow (2.0,(sqrt(sqrt(sqrt(pos)))*198.0-192.0)/6.0);
}


-------------------------------------------------------
This SF.NET email is sponsored by: eBay
Great deals on office technology -- on eBay now! Click here:
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5