On Mon, 23 Jul 2007 10:15:07 +0200 (CEST) Jaroslav Kysela <perex@xxxxxxx> wrote: > On Sun, 22 Jul 2007, stan wrote: > > > On Fri, 20 Jul 2007 13:33:38 +0100 > > Alan Horstmann <gineera@xxxxxxxxxxxxxxx> wrote: > > > > [snip] > > > > > I have less concern with dmix than the hidden rate conversion, but > > > would happily loose both. Using "hw" forces use of 12 capture > > > and 10 playback channels in this case, doesn't it? So I need > > > some plugin to play 2 channels? > > > > > > There are 2 issues for me: > > > > > > 1. With the cards rate state = 'locked' alsa (not sure what bit of > > > it) was unable to set the desired clock rate, yet did not report > > > an error. Data was then eg captured from the card as if it was > > > running at 48K, but actually it remained at 44.1K. Thus the > > > recorded data was wrong. > > > > > > snd_pcm_hw_params_set_rate_near(..) > > > > > > did not report error because it was asking for 44.1K; somewhere > > > else the configuration decided 48K was better, but did not > > > highlight that the card refused to change setting. Surely this > > > should class as a bug. > > > > > > Since the inverse error happens on capture, it is not immediately > > > obvious that there is a problem with the recording, so important > > > recordings could be completely messed up. > > > > > > 2. These ice1712-based pro/semi-pro hardware systems should IMO > > > NEVER perform secret rate conversion. They are designed for > > > readers of 'Sound on Sound' etc, and Paul White et al would > > > rightly blast M-Audio or Terratec if their Windows drivers > > > quietly set the card to a different rate to that requested and > > > rate converted the data! Especially so on a capture stream. > > > Remember the cards are 24-bit 96KHz capable and approach 100dB > > > signal-to-noise ratio. > > > > > > Whilst there may be circumstances in which material recorded at > > > different rates has to be used in the same project, it is only > > > converted once, in full knowledge. > > > > > > Can't dmix be configured to run at whatever rate is set on the > > > card, or the requested rate, rather than attempt to overule both > > > of them? > > > > > > Alan > > > > For what it's worth, I agree with Alan here. Any sound library with > > aspirations to professional use can't have hidden conversions and > > silent corrections going on. > > > > However, I also agree with Takashi that for the average user having > > the dmix plugin as a default is a very good thing. > > > > So, would it be possible to have an api call in the interface to > > disable the dmix plugin for any instance of alsa. For example, I > > call the interface to open the default sound device. Another call > > gets me the hardware associated with the default device. I then > > tell the interface to bypass any filters or plugins, basically > > giving access to the hw interface for whichever card is default for > > this stream only. > > > > Maybe this already exists. If it does, could you point me in the > > right direction (which function). If not, where would it be best > > implemented (which source file)? I don't know that I could or will > > write it, but I would like to have a look at how difficult it would > > be. > > The library is intended to hide all these details for applications. > You can disable sample conversion on demand > (snd_pcm_hw_params_set_rate_resample) to use own better resampler. > > Note that conversions are not used when application asks for > parameters which hw already supports. Of course, dmix is different > thing, but the definition of default device is that it should be > common for most applications. Other applications have possibility to > choose another device / abstraction. These applications can determine > card number and device/subdevice numbers via > snd_pcm_info_get_card,device,subdevice functions and try to open > "raw" hw:card,device,subdevice PCM devices. Thank you Jaroslav, That's what I was looking for. > > Jaroslav > > ----- > Jaroslav Kysela <perex@xxxxxxx> > Linux Kernel Sound Maintainer > ALSA Project, SUSE Labs _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
