[alsa-devel] Maya44 revised patch

[Takashi Iwai]

At Thu, 14 Feb 2008 17:59:05 +0100,
Rainer Zimmermann wrote:
> 
> 
> 
> 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.

That's a good point.

> >>> 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.

Yes, the defnial of opening a capture stream over 96kHz is a drawback
in this method.

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

Either setting a fixed rate via a control or disallow-streams-that-
don't-support way.


> >>> 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...

It's rather your decision at this stage since I have no hardware for
testing.  I'd just like to mention that merging to the upstream gives
more users a chance to try.


> 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?

Well, I think it's fine at this moment since we have (still) no
envy24control for vt172x.  Actually, some other controls are also
candidates to hide from the mixer interface.  We need a more detailed
review in this regard.


Takashi