Takashi Iwai wrote: > >Hmm, did I ever write such a statement? >Please check my reply to your last post with the register dump. >Your info was really appreciated. > My fault for taking objection. Excuses.
> >My RTFM post was not directed to you. >I've seen many bug reports (strangely suddenly at the same time) and I >still don't figure out where the problem lies. On my card it works >quite well. > I can imagine. And the cards seem different in nasty ways. Maybe I can make a register dump in Windows? > >So I wrote this message to make sure people to point out the bug of >the driver, not unexpected usage. >The latter can be of course a bug but it will be easily fixed. >The difficult thing is, to fix the h/w dependent bug without having >its physical existence.. Thus the register dump is the only help. > I agree. And im willing to run a series of tests too - maybe some pathes or a list of values for something. Please make sure that I would test the same way you would. And if anything is important - library version or whatnot - mention it. Same with procedures: reboot in between tests, or even power cycle? Or just unload/modprobe? >>Things still do not work. The option for spdif output that is most >>logical for me, I'm told not to use: DAC to SPDIF. Why not? Is it >>broken? Untested? Anyway the other option doesn't work here either. >> > >No, this switch is usually NOT necessary. This will contaminate the >raw data, for AC3 it's fatal. Thus, this switch is bad for tracing >the bug. Otherwise it's ok, all up to you. > I understand now. > >The SPDF_0 and SPDF_1 bits are set automatically when accessed via >hw:0,2. From my understanding, SPDF_0/1 and ENSPDOUT bits are enough >for spdif output. DAC2SPDO bit is an extra switch to enable the >analog mixture (at least on model 33 and 37). >Perhaps on model 55 SPDO2DAC might be necessary. This correspond(ed) >to "IEC958 Out To DAC" which I requested you to test, _not_ "IEC958 >DAC To Out". I think you didn't test it. > I think I tried most combinations - tests are really quick. But probably not with the aplay command through the spdif device (the one giving timeouts) but with oss playing. > >(I know the naming are confusing. So on the latest cvs version this >switch disappears. It's toggled together with SPDF_0/1 switch.) > Excellent. > >BTW, in ALSA driver the channel 0 is used for playback while OSS >driver uses channel 1. This is because the captuer on SPDIF is >possible only on channel 1. I think SPDIF capture doesn't work on OSS >driver. > Haven't found a way to use it either :( >_I_ also got no information except for the source code of kernel OSS >driver and some trial-and-error. You are not alone :) > Life could be so much easier I guess. > >Anyway, could you try the latest CVS version? I hope now it's fixed. >And if it still doesn't work, the register dump is appreciated. > OK, I'll try it in all logical and illogical combinations I can imagine. May not be this evening, but tomorrow or something. Would it make sense to try other mixer settings when aplay on the spdif device gives errors? Cheers, Thomas _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
