Re: [Alsa-devel] RME96 driver patch
On Sun, Jan 05, 2003 at 04:46:47PM +0100, Anders Torger wrote:
Here is a patch against rme96.c
snd_rme96_capture_spdif_open(snd_pcm_substream_t *substream)
[...]
+ runtime-hw = snd_rme96_capture_spdif_info;
+if ((rate = snd_rme96_capture_getrate(rme96, isadat)) 0) {
+if (isadat) {
+return -EIO;
+}
+runtime-hw.rates = snd_rme96_ratecode(rate);
+runtime-hw.rate_min = rate;
+runtime-hw.rate_max = rate;
+}
You were changing sample rates in snd_rme96_capture_spdif_open. Isn't it too
late there? Looks like capturing with wrong sample rates is now possible?
Wouldn't this be better placed in the snd_rme96_capture_hw_params?
martin
--
2b|!2b
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] RME96 driver patch
On Friday 10 January 2003 15.53, Martin Langer wrote:
On Sun, Jan 05, 2003 at 04:46:47PM +0100, Anders Torger wrote:
Here is a patch against rme96.c
snd_rme96_capture_spdif_open(snd_pcm_substream_t *substream)
[...]
+ runtime-hw = snd_rme96_capture_spdif_info;
+if ((rate = snd_rme96_capture_getrate(rme96, isadat)) 0)
{ +if (isadat) {
+return -EIO;
+}
+runtime-hw.rates = snd_rme96_ratecode(rate);
+runtime-hw.rate_min = rate;
+runtime-hw.rate_max = rate;
+}
You were changing sample rates in snd_rme96_capture_spdif_open. Isn't
it too late there? Looks like capturing with wrong sample rates is
now possible? Wouldn't this be better placed in the
snd_rme96_capture_hw_params?
It is done both in open (show capabilities to the user) and hw params
(the user picks a setting from the available capabilities).
That is, open is performed before hw params, so theoretically it would
only be necessary to do it in open, but it is placed in hw params as
well if the input signal has changed between open and hw params (not
likely).
As mentioned before, this driver does not yet handle the cases when
sample rate and other properties is changed in runtime (I don't know if
ALSA is complete in that respect either). Nothing will break though,
but the user will not be notified of the change, and -EIO may be
delivered (changing from SPDIF to ADAT input signal in runtime for
example).
/Anders Torger
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] RME96 driver patch
At Fri, 10 Jan 2003 16:13:07 +0100, Anders Torger wrote: As mentioned before, this driver does not yet handle the cases when sample rate and other properties is changed in runtime (I don't know if ALSA is complete in that respect either). as far as i've tested before (vari-speed playback on emu10k1 with a mixer control :), changing runtime-rate wouldn't break the middle-level layer if the low-level routines recognizes and handles the change of rates properly. but it's true that there is no offical way to change such a property at runtime except for the sequence: stop, reset hw_params, and start. Takashi --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
