At Tue, 28 Nov 2006 14:13:25 +0100, Erik Slagter wrote: > > Takashi Iwai wrote: > >> iecset allows me to set the rate to 32/44.1/48 kHz, the spdif output is > >> still at 48 kHz. Some other flags from iecset are actually honoured > >> (like "data" and "emphasis"). > > > It's simply because iecset program doesn't support the rates over > > 48kHz. But the hda-intel driver supports the rate, AFAIK. > > (At least, there is no particular code that restricts over-48kHz.) > > The problem is that whatever I set the sampling rate to, the output is > ALWAYS 48 Khz, either set to 32, 41 or 48 Khz. I am not even talking > about the higher rates. > > > One thing to be noted is that if you use "hw" PCM device, you have to > > set up the SPDIF status bits _manually_ via control API. If you use > > "iec958" or "spdif" PCM device, you can pass these bits as optional > > arguments at opening the PCM. > > I've tried that, but it's ehhhrrrmmm lacking some documentation. You have all the source code, what else? :) > >> 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. > >> 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. > 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. 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
