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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
