Hi,

The constraint comes from the codec, the chip itself can handle 192kHz, e.g. the 192kHz SPDIF input works fine. Actually more of the ice1724 cards have this limit. If this issue is solved in a general way, it could be implemented to other cards with 192kHz DACs/96kHz ADCs too.

Pavel

Takashi Iwai wrote:

At Thu, 14 Feb 2008 00:36:07 +0100, Rainer Zimmermann wrote:

...

This is the revised version of the ESI Maya44 patch. changes are mainly coding style, some cleanups and using a patch file for ice1724.c .

The added code now (mostly) passes checkpatch.pl, except for some "#if 0"'s which I'd leave in for the development phase.

Also, I changed the rate setting logic, which (for now) allows all rates up to 192kHz even for capturing. As capturing actually only supports 96 kHz, while capturing & playback rates are linked, this is not really ok. I'd appreciate suggestions about how this could be handled properly, while still supporting playback up to 192 kHz...

Does the 96kHz constraint come from ice172x chip or the codec chip? (I have to recheck the datasheet...)

Anyway, we can limit this in a scenario like below:

• disallow the rate over 96kHz if the capture stream is being opened
• if the rate is set above 96kHz, the capture stream cannot be opened, returns -EBUSY or so.

BTW, is it supposed to be still highly experimental? If the driver works more or less stably with your device (and on the recent kernel), it'd be also good to put this to the upstream, i.e. in alsa-kernel tree instead of alsa-driver tree.

Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Hi Takashi and Pavel,

Takashi Iwai wrote:

...

The constraint comes from the codec, the chip itself can handle 192kHz, e.g. the 192kHz SPDIF input works fine. Actually more of the ice1724 cards have this limit. If this issue is solved in a general way, it could be implemented to other cards with 192kHz DACs/96kHz ADCs too.

Thanks for a quick information. Then, yes, we should fix this issue in general. The separate lists of rates for playback and capture would be required in the end...

ok. Actually, as Pavel mentioned SPDIF, I guess there should be a third set of rates for SPDIF, to be used when the appropriate channel is switched to SPDIF.

...

...

Anyway, we can limit this in a scenario like below: - disallow the rate over 96kHz if the capture stream is being opened - if the rate is set above 96kHz, the capture stream cannot be opened, returns -EBUSY or so.

Yes, I was thinking of something along those lines. But 2 possible issues:

- maybe a stupid question, but couldn't there be some "backdoor"? E.g., could a playback stream change its rate to above 96kHz while a capture stream is open?

- In the latter case, I think it should read: "if a playback stream is running at above 96kHz, the capture stream cannot be opened". Otherwise, e.g. arecord couldn't open the device if another app left the rate at 192kHz.

Are there other examples (non-ice17xx) how this is handled?

...

...

BTW, is it supposed to be still highly experimental? If the driver works more or less stably with your device (and on the recent kernel), it'd be also good to put this to the upstream, i.e. in alsa-kernel tree instead of alsa-driver tree.

Yes, so far the driver is stable on my system (2.6.22) and on Piotr's, but I would still consider it experimental. It still contains experimental code and some experimental controls, and I guess there should be more testing, in particular the MI/ODI/O and SPDIF part is still untested. Well, your decision...

As for the vu-meters:

Since the meaning of these read-only controls is clear only upon detailed study of the driver and Envy24 datasheet plus I encounter a lot of questins/complaints about them, I suggest to change their type from MIXER to PCM. They would still be readily accessible from amixer or API.

No objection from my part, but could it break any app software? any other comments?

-Rainer