Hi Thomas, At Sun, 27 Jan 2002 11:28:51 +0100, Thomas Tonino wrote: > > > > >ok, obviously there have been enough problems regarding $SUBJECT. > >I don't think that all bug reports on ML are really one, though. > >So, please check the following if you have encountered this problem. > > > >**** > > > >1. For playing through SPDIF, you need to use the 3rd device, > >namely, > > % aplay -Dhw:0,2 foo.wav > > > > aplay -Dhw:0,2 test.wav > Playing WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo > aplay: pcm_write:935: write error: Input/output error > > A strace: > ioctl(4, 0x400c4150, 0xbffff6c0) = 0 > read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., > 16384) = 16 > 384 > ioctl(4, 0x400c4150, 0xbffff6c0) = 0 > read(3, "\305\1\212\1\364\2^\2\23\4+\0038\5\366\3U\6\264\4\\\7e"..., > 16384) = 16 > 384 > ioctl(4, 0x400c4150, 0xbffff6c0) = ? ERESTARTSYS (To be restarted) > --- SIGWINCH (Window changed) --- > ioctl(4, 0x400c4150, 0xbffff6c0) = ? ERESTARTSYS (To be restarted) > --- and so on --- > ioctl(4, 0x400c4150, 0xbffff6c0) = ? ERESTARTSYS (To be restarted) > --- SIGWINCH (Window changed) --- > ioctl(4, 0x400c4150, 0xbffff6c0) = -1 EIO (Input/output error) > write(2, "aplay: pcm_write:935: ", 22aplay: pcm_write:935: ) = 22 > write(2, "write error: Input/output error", 31write error: Input/output > error) = 31 > write(2, "\n", 1 > ) = 1 > _exit(1) = ? Oh well.. clearly a bug.
> > > >2. There are many different models with the same CM8738 chip. > > > Mine is model 55. > > I'm giving up on Alsa for the time being. I like the project really much > - even ran a public mirror a long time ago - but I think it currently > lacks quality. The architecture may be great, but if things don't work, > there is not much in it for users. > > I realize the 0.9 version is a beta. I also realize I have a working oss > style driver available. And I would really prefer Alsa on my system. But > I think it has to be in kernel 2.5 before it will really work - > hopefully more user oriented bug reports will come in. > > I'm not a C hacker, but I have given some code and algorithms > incorporated into other projects. The style of development here doesn't > help me be productive, however. People here have great ideas and insight > in architectural matters, but are not good at getting others up to speed > fixing things. > > For example, I would have liked trying some register settings on my > system to figure out what works and what doesn't. Instead what happened: > > First, I report a problem > Then, the answer: it is not broken, read the docs 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 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. 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. > After that, I start mangling the source, find out about the > signed/unsigned workaround (which can be done through aplay as well it > seems... but maybe the docs should be more accessible?) In any case > other testers are more clever than me. Only when other bug reports come > in, things are picked up and people realize there _might_ be a problem. Actually your workaround had been in CVS sometime ago but now removed because there have been many changes done recently. (and the signed/unsigned workaround is not the correct solution.) > 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. 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 know the naming are confusing. So on the latest cvs version this switch disappears. It's toggled together with SPDF_0/1 switch.) 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. > I would have been more than willing to write documentation for end > users. But I'm fed up with getting no information, not even pointers to > them (except "read CMIPCI.txt"). _I_ also got no information except for the source code of kernel OSS driver and some trial-and-error. You are not alone :) 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. ciao, Takashi _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
