Minor bug(s) in hdsp.c (RME HDSP driver)

Minor bug(s) in hdsp.c (RME HDSP driver)

[Anders Torger]

In hdsp.c (CVS):

The function hdsp_set_rate() returns -1 on error, which equals -EPERM. 
snd_hdsp_hw_params() returns the return value of hdsp_set_rate() on 
failure, thus if hdsp_set_rate() cannot be set, then -EPERM is coming 
out of alsa-lib.

I also think that the behaviour of hdsp_set_rate() should change. If the 
card is set to AutoSync, and there is no input signal, hdsp_set_rate() 
will fail on line 888. In this case, I think the proper behaviour would 
be to set the card in Master mode with the given rate.

----

At the same time I'd like to ask a question. The card I have on my hands 
is a HDSP 9652 PCI card. I have noticed that it has some DSP mixer, and 
that there are volume control settings in the driver. I want the card 
to work just like a good ol' RME9652 (that is no volume control no 
mixing, what comes in comes in, what goes out goes out), will it do 
that per default, or do I have to raise some volume controls and do 
other stuff to deactivate the mixer?

I would test if I could, the problem is that the HDSP card I'm working 
with sits in a computer across the pond, and my only access is through 
a slow internet connection, so I'm very limited when it comes to 
hearing sound and moving cables. For the same reason it is not suitable 
that I would write patches for the above, since I can't hear if I have 
broken something.

/Anders Torger



-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
same time. Free trial click here: http://www.vmware.com/wl/offer/345/0

Re: Minor bug(s) in hdsp.c (RME HDSP driver)

[Paul Davis]

>The function hdsp_set_rate() returns -1 on error, which equals -EPERM. 
>snd_hdsp_hw_params() returns the return value of hdsp_set_rate() on 
>failure, thus if hdsp_set_rate() cannot be set, then -EPERM is coming 
>out of alsa-lib.

will fix.

>I also think that the behaviour of hdsp_set_rate() should change. If the 
>card is set to AutoSync, and there is no input signal, hdsp_set_rate() 
>will fail on line 888. In this case, I think the proper behaviour would 
>be to set the card in Master mode with the given rate.

seems sensible.

>At the same time I'd like to ask a question. The card I have on my hands 
>is a HDSP 9652 PCI card. I have noticed that it has some DSP mixer, and 
>that there are volume control settings in the driver. I want the card 
>to work just like a good ol' RME9652 (that is no volume control no 
>mixing, what comes in comes in, what goes out goes out), will it do 
>that per default, or do I have to raise some volume controls and do 
>other stuff to deactivate the mixer?

i nearly added an option to let it run like an rme9652, but didn't. if
you don't activate the mixer, you get rme9652-like behaviour. i can
add this, or you can. its very simple.

--p


-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
same time. Free trial click here: http://www.vmware.com/wl/offer/345/0

Re: Minor bug(s) in hdsp.c (RME HDSP driver)

[Case van Rij]

I for one would love to see the option to have the HDSP 9652 behave the
same way as RME9652.. I ended up with 3 different cards in 3 otherwise
identical systems (Digi9636. Digi9652, and HDSP9652) anything to make
them look more alike would be great.

One problem Ive noticed with the Digi9636 however, and im still waiting
to see it happen on the other systems, is that it stops recording after
a while if I run the following loop:

while true; do 
arecord -D plug:hw:0 -t wav -c 18 -r 22050 -I -f S16_LE `date +%s`.wav; 
done

after a few days it ends up in a loop 
ioctl(4, 0x80044121, 0xbfffee18) = 0 
poll([{fd=4, events=POLLIN|POLLERR|POLLNVAL}], 1, 1000) = 0

killing arecord doesnt fix it, a reboot does. Anything I can do to
figure out what state ended up in ? 

RME Digi9636 (Rev 1.5) with alsa-lib|driver 0.9.4 on kernel 2.4.20smp

Case

On Sat, Jul 19, 2003 at 01:47:54PM -0400, Paul Davis wrote:
> >The function hdsp_set_rate() returns -1 on error, which equals -EPERM. 
> >snd_hdsp_hw_params() returns the return value of hdsp_set_rate() on 
> >failure, thus if hdsp_set_rate() cannot be set, then -EPERM is coming 
> >out of alsa-lib.
> 
> will fix.
> 
> >I also think that the behaviour of hdsp_set_rate() should change. If the 
> >card is set to AutoSync, and there is no input signal, hdsp_set_rate() 
> >will fail on line 888. In this case, I think the proper behaviour would 
> >be to set the card in Master mode with the given rate.
> 
> seems sensible.
> 
> >At the same time I'd like to ask a question. The card I have on my hands 
> >is a HDSP 9652 PCI card. I have noticed that it has some DSP mixer, and 
> >that there are volume control settings in the driver. I want the card 
> >to work just like a good ol' RME9652 (that is no volume control no 
> >mixing, what comes in comes in, what goes out goes out), will it do 
> >that per default, or do I have to raise some volume controls and do 
> >other stuff to deactivate the mixer?
> 
> i nearly added an option to let it run like an rme9652, but didn't. if
> you don't activate the mixer, you get rme9652-like behaviour. i can
> add this, or you can. its very simple.
> 
> --p
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: VM Ware
> With VMware you can run multiple operating systems on a single machine.
> WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
> same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-devel


-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
same time. Free trial click here: http://www.vmware.com/wl/offer/345/0

Re: Minor bug(s) in hdsp.c (RME HDSP driver)

[alsa-devel]

Quoting Paul Davis <paul@linuxaudiosystems.com>:

> >I also think that the behaviour of hdsp_set_rate() should change. If the 
> >card is set to AutoSync, and there is no input signal, hdsp_set_rate() 
> >will fail on line 888. In this case, I think the proper behaviour would 
> >be to set the card in Master mode with the given rate.
> 
> seems sensible.
> 

I disagree.  If the card is set to AutoSync and there is no input
signal anywhere, this would probably be a problem with cabling or routing
somewhere.  From an end-user perspective, I would want giant red lights 
flashing on my screen telling me things are wrong.  The last thing I
would want is for a low-level software component to silently switch to
master mode.  This would likely cause sample-slipping with some other
piece of hardware, and if the sample rates are close, this may very well
not be detected by cursory audio monitoring (and only noticed after you
have the "perfect take" down).

Of course, if the application knows about slave synchronization, I
would expect it never to call a function to set the sample rate -- only
check the rate.  But a lot of app's don't work this way.  I've played
back a 44.1kS/s file when externally synced to 48kS/s and it comes out
too high/fast.  This is usually pretty easy to detect by listening, so
it's not a horrible problem, but some sort of warning would be better
(naturally this depends on the application, but it requires that the
library return some sort of abnormal status in this case).

The behavior that seems best to me would be to return an error when
1) AutoSync is selected and 2) the sample rate given is not within 400ppm
of the current external sync or there is no valid external sync signal
Then, let the application decide on the policy to implement in these
cases.

Of course, I'm not sure how well this meshes with the overall
ALSA system model and "consumer" style sound cards.  It's just that
sample rate timing/sync (and the associated problem of jitter) is
probably the single biggest issue in distribution of digital audio 
in a professional environment, so this is my USD2*10E-2.

--Rob Dye



-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
same time. Free trial click here: http://www.vmware.com/wl/offer/345/0

Re: Minor bug(s) in hdsp.c (RME HDSP driver)

[Paul Davis]

>Quoting Paul Davis <paul@linuxaudiosystems.com>:
>
>> >I also think that the behaviour of hdsp_set_rate() should change. If the 
>> >card is set to AutoSync, and there is no input signal, hdsp_set_rate() 
>> >will fail on line 888. In this case, I think the proper behaviour would 
>> >be to set the card in Master mode with the given rate.
>> 
>> seems sensible.
>> 
>
>I disagree.  If the card is set to AutoSync and there is no input

on 2nd thoughts, so do i. more concisely, if the sync source is
AutoSync, then any call to hdsp_set_rate(0 should fail, independently
of whether there is a sync-able input signal or not.

--p


-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
same time. Free trial click here: http://www.vmware.com/wl/offer/345/0