At Mon, 16 Mar 2009 15:31:58 +0100, Andreas Mohr wrote: > > Hi, > > On Mon, Mar 16, 2009 at 03:18:20PM +0100, Takashi Iwai wrote: > > At Mon, 16 Mar 2009 14:30:01 +0100, > > Andreas Mohr wrote: > > > > > > Hi, > > > > > > On Mon, Mar 16, 2009 at 01:09:50PM +0100, Takashi Iwai wrote: > > > > The question in the top priority is whether it's a kernel driver > > > > issue or alsa-lib converter issue. Could you check whether the sounds > > > > recorded with -Dhw (and with matching rate, format, etc) have the same > > > > noise problem at first? > > > > > > OK, tried arecord -v -D hw:0 -c1 test.wav, which ended with > > > arecord: set_params:961: Sample format non available > > > . > > > > > > arecord -v -D hw:0 -c1 -f S16_LE test.wav then ended with > > > arecord: set_params:966: Channels count non available > > > thus completing it into a > > > arecord -v -D hw:0 -c2 -f S16_LE test.wav > > > worked. > > > > > > Trying this line with plughw then worked (of course, since two channels > > > never has any problems). > > > > > > Interestingly when using plughw there seems to be some LPF effect, since > > > with hw I get lots of white noise whereas with plughw the recorded sound > > > is dark (no higher-frequency components at all). > > > > > > And audio is always being recorded properly no matter which Capture > > > sliders position. > > > > > > To state it more clearly, both hw and plughw have no issues whatsoever > > > with -c2 -f S16_LE, any sliders position. > > > If I then switch to plughw:0 -c2 -f U8 (IOW change to U8 format), > > > no problems either. Trouble starts if I then change to -c1 and have > > > both channel sliders about equal (if they're not equal then I'm getting > > > audio returned properly). > > > > So, the following is also problematic > > > > % arecord -fdat -c1 -Dplughw ng.wav > > > > while the below works? > > > > % arecord -fdat -Dhw good.wav > > Indeed, the above has problems with problematic slider positions whereas > the below never has. Err, could you be more specific about "slider positions"? > > > > And, if it's about the alsa-lib conversion problem, we can reproduce > > > > without the hardware, e.g. via file plugin... > > > > > > So, what to do? > > > > Does the conversion by sox from good.wav to a mono-channel file work? > > I assume I should be using > sox good.wav -c1 good1.wav > ? > > If so, yes, this works, audio is there. Just to be sure - what about below? sox good.wav -c1 good1.wav mixer 0.5,0.5 Takashi -- To unsubscribe from this list: send the line "unsubscribe kernel-testers" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html