At Thu, 19 Jul 2007 15:24:40 +0100, John Rigg wrote: > > On Thu, Jul 19, 2007 at 11:33:32AM +0200, Takashi Iwai wrote: > > At Wed, 18 Jul 2007 17:20:29 +0100, > > Alan Horstmann wrote: > > > > > > On Wednesday 18 July 2007 16:01, Alan Horstmann wrote: > > > > Yes and yes. Using "hw" gives the same wrong speed with -lasound, and > > > > standard command-line aplay does also. Evidently I understand even less > > > > than I thought. I had expected that with the card hardware set to 44100Hz > > > > and locked, that playing a 44100Hz file would be straightforward. Maybe > > > > the file is not right. I may have to pause testing for a few days now. > > > > > > Actually, I think I have an idea what is happening, but not why. > > > > > > aplay -v TMP/try3.wav > > > > > > Playing WAVE 'TMP/try3.wav' : Signed 32 bit Little Endian, Rate 44100 Hz, > > > Channels 10 > > > Plug PCM: Rate conversion PCM (48000, sformat=S32_LE) > > > Its setup is: > > > stream : PLAYBACK > > > access : RW_INTERLEAVED > > > format : S32_LE > > > subformat : STD > > > channels : 10 > > > rate : 44100 > > > exact rate : 44100 (44100/1) > > > msbits : 32 > > > buffer_size : 5644 > > > period_size : 940 > > > period_time : 21333 > > > tick_time : 0 > > > tstamp_mode : NONE > > > period_step : 1 > > > sleep_min : 0 > > > avail_min : 940 > > > xfer_align : 940 > > > start_threshold : 5640 > > > stop_threshold : 5644 > > > silence_threshold: 0 > > > silence_size : 0 > > > boundary : 1479540736 > > > Slave: Direct Stream Mixing PCM > > > Its setup is: > > > stream : PLAYBACK > > > access : MMAP_INTERLEAVED > > > format : S32_LE > > > subformat : STD > > > channels : 10 > > > rate : 48000 > > > exact rate : 48000 (48000/1) > > > msbits : 24 > > > buffer_size : 6144 > > > period_size : 1024 > > > period_time : 21333 > > > tick_time : 0 > > > tstamp_mode : NONE > > > period_step : 1 > > > sleep_min : 0 > > > avail_min : 1024 > > > xfer_align : 1024 > > > start_threshold : 6144 > > > stop_threshold : 6144 > > > silence_threshold: 0 > > > silence_size : 0 > > > boundary : 1610612736 > > > Hardware PCM card 0 'TerraTec DMX6Fire' device 0 subdevice 0 > > > Its setup is: > > > stream : PLAYBACK > > > access : MMAP_INTERLEAVED > > > format : S32_LE > > > subformat : STD > > > channels : 10 > > > rate : 48000 > > > exact rate : 48000 (48000/1) > > > msbits : 24 > > > buffer_size : 6553 > > > period_size : 1024 > > > period_time : 21333 > > > tick_time : 1000 > > > tstamp_mode : NONE > > > period_step : 1 > > > sleep_min : 0 > > > avail_min : 1024 > > > xfer_align : 1024 > > > start_threshold : 1 > > > stop_threshold : 1717829632 > > > silence_threshold: 0 > > > silence_size : 1717829632 > > > boundary : 1717829632 > > > > > > It attempts to set the card to 48000, which fails since I have it locked! > > > When I recorded the file the same was true, so from "default" the file plays > > > back correct although it is in fact wrong, and plays wrong when imported into > > > Audacity. The set-up listed above suggests to me that Alsa is rate > > > converting to 48000 and Mmap'ing to the card. If correct, is that really > > > necessary? I dislike any rate conversions on a serious recording system, and > > > especially hidden ones. Is this a configuration issue that might have > > > changed since, say, 1.0.10 or 1.0.12? > > > > The 48k-fixed rate is due to dmix plugin. It requires a fixed sample > > rate for all apps. In theory, it may accept multiple rates, but the > > feature is not implemented yet. > > > > You can change the default rate by overriding defaults.pcm.dmix.rate > > config item, e.g. define the below in ~/.asoundrc: > > > > defaults.pcm.dmix.rate 44100 > > Wouldn't it be better to specify hw:0 (or whatever card you are using) > in this case? With this type of hardware I'd rather make sure that dmix > isn't used at all (I assume that dmix is now the default instead of > hw:0). Well, you can claim that because you don't get bug reports or rants ;) The only reason that plug+dmix is used is that it can handle most cases without hitches. It works as it is. That's all above other reasons. Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
