Hi, [Don't forget add alsa-devel to Cc] At Tue, 28 Nov 2006 19:42:30 +0100, Erik Slagter wrote: > > >>>> I can ask aplay to play at various rates (from a suitable PCM file), but > >>>> it complains at any other rate than 44.1 or 48 (notably 32) kHz that the > >>>> rate is not supported. It plays at 44.1 kHz though. And again converts > >>>> it to 48 kHz! Sigh... > >>> Who complains? At least, the driver won't. > >> aplay complains, I suspect as a result of a return value from the > >> driver. I can give you the output if it helps. I can even do an strace. > > > strace doesn't help much, I guess. Provide rather what exactly you > > did and what exactly you got, at first. I can't reproduce nor check > > anything unless I get precise information. Also, try always the > > latest version if you want to debug/analyzie something, i.e. ALSA HG > > version. > > HG??? Mercurial. See the download page. > I can give you output of the FC5 versions, i.e. 1.0.11 That's way too old version. > Anyway, I'm only using aplay and iecset from it. > > The kernel is 2.6.18, I did try 2.6.19-rc4, but it has too many > problems, and for alsa functionality it doesn't appear to matter anyway. > > If you happen to have a few lines of C code that does no more than > setting the output digital device to sample rate x, I'd be obliged. > > Also I really don't get the relationship between the sample rate of the > wav file I'm using for testing (with aplay) and iecset. I'd expect that > aplay would set the sample (locking) rate of the spdif interface to the > sample frequency as the wav file, what is the use of iecset (rate) then? > I am using hw:0,0 to really avoid software resampling. Well, still I didn't write what you did and what you got... > >>>> Maybe I am using the wrong "hw", there is also a "hw:0,2" device, which > >>>> I cannot make work properly at all (only one channel is output, large > >>>> chunks are discarded, much much clipping). > >>> The first PCM device is for the multi-output PCM. It's for both > >>> analog and digital. The dedicated SPDIF is the secondary one. > >> But why does the second interface gives _some_ (although wrong) output > >> on my spdif output then? > > > No idea, possibly wrong parameters are passed. > > By whom or what? Actually I don't care that much, but it looks like a > bug to me. Possibly. But too little information to analyze. > >> Anyway, I double checked and the alc882 CAN output at various rates, > >> also on the sp/dif output. > > > It's likely true. Better to check the proc file content of codec#* > > file rather than reading datasheets (what are often wrong), though. > > I did try to parse this file, but I could not make anything useful out > of it. I attached it for your convenience. > > I also tried to decipher the "rates" values from the constants in the > source code, but it's really not doable (include include define include > etc.) Try HG version, and you'll see what they mean better. Anyway, I'll be in vacation for a couple of weeks from tomorrow, so the debugging is likely pending... Takashi ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-devel
