> > > > >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) = ? > >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 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. 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. 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"). And because of the feeling that I've not made any progress, I wish you all good luck with the project. And I hope it does not become the critical path in releasing the 2.6 kernel. But then again, being in 2.5 may mean there is a manager to give priority to bug fixing. No hard feeling, but a little sad. Especially as the problem I'm reporting - very loud distorted sound - should always be a bug. Especially for a project that prides itself for keeping mixer volume levels at zero by default. Good luck, Thomas _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
