Thread: [Alsa-user] C-Media 8738 SPDIF problem
Brought to you by:
perex
From: Takashi I. <ti...@su...> - 2002-01-24 16:45:31
|
Hi, 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 or alternatively % aplay -Dspdif foo.wav For ac3dec, you don't need specify -D option (except for model 33; see below) 2. There are many different models with the same CM8738 chip. And the configuration is a bit different on each model. The model number can be checked via /proc/asound/cards. (My sound card has model 37, BTW.) The spdif has been tested only on model 37 and 33, so far. If your chip has another model number, please let me know. The model 33 has a bug on AC3 mode. If this happens, try to specify the pcm device explicitly, for example, like below for ac3dec: % ac3dec -C -Dhw:0,2 foo.ac3 i'm trying to fix this problem now.. 3. Don't turn on "IEC958 Out To DAC" switch. This is necessary only when WAV and FM must be mixed. 4. Check whether "IEC958 In Phase Inverse" is correct when you'll receive signales via SPDIF. 5. It seems that the dip switch on board has priority for the selection of digital i/o, coax or optical. When you use coax i/o and it doesn't work, check the h/w setting together with "IEC958 5V" switch. 6. Please read doc/CMIPCI.txt. **** If the same bug still remains, please report the symptom together with the dump of /proc/asound/card0/cmipci and the model number of your card! ciao, Takashi |
From: Thomas T. <tt...@us...> - 2002-01-27 11:05:03
|
> > > > >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 |
From: James Courtier-D. <Ja...@su...> - 2002-01-27 17:01:24
|
If you read posts from the alsa-devel list, you would see lots of advice on how to get it to work, apart from just RTFM. The most important part is the correct feedback from yourself. I am only saying this as an impartial observer. I have found that the developers on this list give very good support if one gives them the information they ask for. I myself had a big problem with SPDIF pass thru on a SB Live, which we finally managed to fix, although it took a long time, due to the issue that I could see the problem, but the developers SB Live worked fine. There are many different versions of sound cards. They might all be called "SB Live" or "C-Media 8738", but the actual hardware can be quite different. So when one of the developers(Takashi Iwai) asked for specific information from the users on 24-1-2002, why didn't you respond. Cheers James > -----Original Message----- > From: als...@li... > [mailto:als...@li...]On Behalf Of Thomas > Tonino > Sent: 27 January 2002 10:29 > To: als...@li... > Cc: als...@li... > Subject: [Alsa-devel] Re: [Alsa-user] C-Media 8738 SPDIF problem > > > > > > > > > > > >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 > Als...@li... > https://lists.sourceforge.net/lists/listinfo/alsa-devel |
From: Thomas T. <tt...@us...> - 2002-01-28 07:30:32
|
James Courtier-Dutton wrote: >If you read posts from the alsa-devel list, you would see lots of advice on >how to get it to work, apart from just RTFM. > True. But it didn't work for me. The first time I posted a bug report I got the RTFM response. I did, and after a while came: yeah, spdif doesn't work here either. Grrr. That doesn't help me or anyone else figure out what is going on. I can imagine this happens, but with quicker turnaround and some 'try this' instructions we would have gotten a result much quicker. > >The most important part is the correct feedback from yourself. >I am only saying this as an impartial observer. I have found that the >developers on this list give very good support if one gives them the >information they ask for. I myself had a big problem with SPDIF pass thru on >a SB Live, which we finally managed to fix, although it took a long time, >due to the issue that I could see the problem, but the developers SB Live >worked fine. > True. The developers are doing a great job - Alsa is a very useful project that provides a lot of functionality. It is just a pity that only on the 24th there was a remark to use aplay and suggestions on the mixer settings. Having a test that is the simplest possible helps immensely. > >There are many different versions of sound cards. >They might all be called "SB Live" or "C-Media 8738", but the actual >hardware can be quite different. > Absolutely true. This seems to be the root of the matter My hardware is a newer version, and I do not think c-media has much in the way of docs except for their source code. > >So when one of the developers(Takashi Iwai) asked for specific information >from the users on 24-1-2002, why didn't you respond. > My message gives a reaction to his question: that playing through the spdif device doesn't work at all, instead failing with timeouts and I/O errors. I also gave a register dump - I also made when the latest oss style driver was running. And I'm willing to try more, but please let it be done in a useful manner: what modules I load and what software I run with what settings and options. The situation where I say "oss sfdif out doesn't work" and the response is 'use aplay and do not use dac to spdif but use the spdif device' - and then I try to guess how to use the spdif device (while giving the command line in the first place should be easy). And then, when it doesn't work, I still have no idea? Should I use plug, hw, or hwplug device? Etc. This is more a bug management thing than anything else. Maybe someone should step in to help categorize and combine bugs - but the the maintainers are best at understanding what goes wrong. But maintainers must realize that users are not experts in using the software yet. Not fully understanding the application (just trying it out, see if it works), but with the feeling that something is not working for them. A simple test case (in this case the aplay command, maybe clearing of certain settings files too, and so on) then is so much more helpful than an RTFM. Even better for me would be to get an instruction to build the driver, but change the value of a certain #define to all bit masks from 0x00 to 0x80, and see if anything works. Easy way to help out, and takes less time than waiting for a response, updatin a cvs tree, and rebuilding. I agree I am probably getting upset at the wrong time, just when the bug reports are bundled. I'm unsubscribed from the list now, and will try the occasional beta release if there are any c-media related changes. And if anyone wants, I can try some targeted changes and I will document what works and what doesn't, or if a certain bit has a certain effect. Mail me privately if that is desired. And finally, if a lot of bogus bug reports come in, something may be wrong with the defaults. In any case, I'm off the list for now. A bit sad, because Alsa is nicer than Oss. But feel free to mail. I'll do the occasional test of a release version, and if I think there is something worthwhile to mention I'll do. Thomas |
From: Takashi I. <ti...@su...> - 2002-01-28 12:15:48
|
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 |
From: Thomas T. <tt...@us...> - 2002-01-28 14:30:40
|
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 |
From: Takashi I. <ti...@su...> - 2002-01-28 15:27:38
|
Hi Thomas, At Mon, 28 Jan 2002 15:30:31 +0100, Thomas Tonino wrote: > > > > >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? Well, it would be nice if possible, but i don't know how to do it on windows.. Do you have any clue? > >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? The library version is likely irrevelant, if this is a driver problem. Loading/unloading should be enough: one can test driver A -> B -> A, wheere A: ALSA, B: OSS, so that we know A doesn't work :) > >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? Ok, then please check the following: - Disable all "IEC958 *" switches except for "IEC958 Output Switch" (probably "IEC958 5V" too) - run "aplay -Dhw:0,2 foo.wav" and get dump from /proc/asound/card0/cmipci. If it still doesn't work, try to swap channel 0 and channel 1 by changing the definition around line 297 like below: #define CM_CH_PLAY 1 // 0 as default #define CM_CH_CAPT 0 // 1 as default then rebuild the driver and install it. (Now you'll need to turn the switch "Exchange DAC" on for getting output from analog speaker.) And please try the same procedure as above. This one should be fairly identical with OSS driver's configuration. So the difference can be easily compared by register dumps. Thanks. ciao, Takashi |
From: Thomas T. <tt...@us...> - 2002-01-31 13:34:20
|
Takashi Iwai wrote: > >- Disable all "IEC958 *" switches except for "IEC958 Output Switch" > (probably "IEC958 5V" too) >- run "aplay -Dhw:0,2 foo.wav" and get dump from > /proc/asound/card0/cmipci. > This works: I get output on analog and on spdif. Hurray! Some further experiments: setting iec958 in monitor to M mutes the analog out ((replaced by the spdif input? doesn't work, isn't this label working in reverse btw?), but I cannot hear the incoming spdif signal on analog out, no matter what settings I try. This is with optical and electrical connected at the same time. But, we have the same level of functionality as OSS. Good! Still, the Mix Analog option does not work. Gives full scale output on the DAT VU meter. No sound though - looks like full scale DC. > >If it still doesn't work, try to swap channel 0 and channel 1 by >changing the definition around line 297 like below: > >#define CM_CH_PLAY 1 // 0 as default >#define CM_CH_CAPT 0 // 1 as default > Didn't try this. By the way, would it make sense to have the hw:0,2 device as default? It uses the same analog out as the normal output, but enables spdif. Or will this break cards without spdif? I'm now off to windows, try to get a register dump there... Thomas |
From: Takashi I. <ti...@su...> - 2002-01-31 13:33:12
|
Hi Thomas, At Wed, 30 Jan 2002 22:18:42 +0100, Thomas Tonino wrote: > > Takashi Iwai wrote: > > > > >- Disable all "IEC958 *" switches except for "IEC958 Output Switch" > > (probably "IEC958 5V" too) > >- run "aplay -Dhw:0,2 foo.wav" and get dump from > > /proc/asound/card0/cmipci. > > > This works: I get output on analog and on spdif. Hurray! Yeah, good to know! > Some further experiments: setting iec958 in monitor to M mutes the > analog out ((replaced by the spdif input? doesn't work, isn't this label > working in reverse btw?), but I cannot hear the incoming spdif signal on > analog out, no matter what settings I try. This is with optical and > electrical connected at the same time. On mine, the signal comes to analog when both "IEC958 In Monitor" and "IEC958 Output Switch" are on. > But, we have the same level of functionality as OSS. Good! > > Still, the Mix Analog option does not work. Gives full scale output on > the DAT VU meter. No sound though - looks like full scale DC. Ok, i'll remove this switch for the cards later than model 39. Looks like this working only for the old chips.. > >If it still doesn't work, try to swap channel 0 and channel 1 by > >changing the definition around line 297 like below: > > > >#define CM_CH_PLAY 1 // 0 as default > >#define CM_CH_CAPT 0 // 1 as default > > > Didn't try this. Not necessary now. It seems that the assignment of channel is not involved with the problem. > By the way, would it make sense to have the hw:0,2 device as default? It > uses the same analog out as the normal output, but enables spdif. Or > will this break cards without spdif? I'll work on it. ciao, Takashi |
From: Takashi I. <ti...@su...> - 2002-01-31 13:32:39
|
At Thu, 31 Jan 2002 09:30:46 +0100, I wrote: > > > > By the way, would it make sense to have the hw:0,2 device as default? It > > uses the same analog out as the normal output, but enables spdif. Or > > will this break cards without spdif? > > I'll work on it. Done. Now committed cvs. please give a try. Takashi |
From: Thomas T. <tt...@us...> - 2002-02-16 21:39:37
|
Takashi Iwai wrote: > >Done. Now committed cvs. >please give a try. > Sorry for responding so late. Here are the results for the cmipci driver cvs version as of today: I see no way to listen to a signal on the digital input. In a standard setting, there is no signal on the normal analog output. I can get analog out by: unmute IEC958 Output (this enables digital out, as expected) unmute IEC958 In Monitor (strangely enough, this routes the IEC output to the internal DAC) When I input an spdif signal, this has no effect. When I enable SPDIF loop, the SPDIF signal goes, but the internal DAC keeps playing with the above settings. But both IEC958 Output and IEC958 In Monitor need to be enabled to get analog out. But with SPDIF loop on, I see no way to get a signal in the coaxial input repeated on the output and/or DAC. In the above setting, the PCM volume slider and mute controls have no effect. Cheers, Thomas |
From: Thomas T. <tt...@us...> - 2002-02-16 22:00:10
|
One more funny thing when playing a 44k mono signal, there is no output on spdif, and neither is there on the DAC. Some soft squishing noises perhaps, but nothing more. Maybe the 44 k reported by xmms is not exact. Or maybe mono is the problem? Cheers, Thomas |