[alsa-devel] Wandboard Quad - SPDIF issue, no sound
Hello All,
I'm resending this email as orignally I wasn't subcribed and I've been told the message hasn't made it through.
I was pointed here from the Wandboard Google Groups forum. If I'm in the wrong place please accept my appologies.
With known good cabling and receiver I'm not getting sound from the Wandboard Quad's S/PDIF output. I have built various kernels from mainline, the last two sources I tried are 3.15.1 and 3.16-rc2.
With sound built as modules I get nothing on any outputs, errors from dmesg are;
dmesg | grep snd 5.206990] imx-spdif sound-spdif.13: snd_soc_register_card failed: -517 [ 5.241976] imx-spdif sound-spdif.13: snd_soc_register_card failed: -517 [ 5.258174] imx-spdif sound-spdif.13: snd-soc-dummy-dai <-> 2004000.spdif mapping ok [ 5.281704] imx-sgtl5000 sound.12: snd_soc_register_card failed (-517)
With sound built in I get sound on the 'line out' output and from dmesg;
dmesg | grep snd imx-spdif sound-spdif: snd-soc-dummy-dai <-> 2004000.spdif mapping ok
In both cases I get (or similar);
dmesg | grep firm imx-sdma 20ec000.sdma: Direct firmware load failed with error -2 imx-sdma 20ec000.sdma: loaded firmware 1.1
Not sure if the firmware message above is a problem or not.
aplay output;
aplay -l **** List of PLAYBACK Hardware Devices **** card 0: imx6wandboardsg [imx6-wandboard-sgtl5000], device 0: HiFi sgtl5000-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: imxspdif [imx-spdif], device 0: S/PDIF PCM snd-soc-dummy-dai-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0
aplay -L null Discard all samples (playback) or generate zero samples (capture) pulse PulseAudio Sound Server sysdefault:CARD=imx6wandboardsg imx6-wandboard-sgtl5000, Default Audio Device sysdefault:CARD=imxspdif imx-spdif, Default Audio Device
aplay -vv ImABeliever.wav Playing WAVE 'ImABeliever.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo Hardware PCM card 1 'imx-spdif' device 0 subdevice 0 Its setup is: stream : PLAYBACK access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 44100 exact rate : 44100 (44100/1) msbits : 16 buffer_size : 16384 period_size : 4096 period_time : 92879 tstamp_mode : NONE period_step : 1 avail_min : 4096 period_event : 0 start_threshold : 16384 stop_threshold : 16384 silence_threshold: 0 silence_size : 0 boundary : 1073741824 appl_ptr : 0 hw_ptr : 0 ################# + | 55%
but no sound form SPDIF.
If this is right place for this and if I can be of any help debuuging or you need more info I'm more than happy to help in any way I can.
Since I sent the original message Ive realised that data is being sent to and received at the SPDIF output of the wandboard quad it can't seem to handle it. If I connect a DAC to the SPDIF output and then connect the DAC to my recievers aux input I hear the sound in all it's glory.
The same receiver and cabling works with a cubietruck and the sunxi kernel.
Cheers, Mike
Hi Micheal
On 06/23/2014 02:07 PM, Michael Howard wrote:
Hello All,
I'm resending this email as orignally I wasn't subcribed and I've been told the message hasn't made it through.
I was pointed here from the Wandboard Google Groups forum. If I'm in the wrong place please accept my appologies.
With known good cabling and receiver I'm not getting sound from the Wandboard Quad's S/PDIF output.
How are you testing your spdif output exactly ?
I have built various kernels from mainline, the last two sources I tried are 3.15.1 and 3.16-rc2.
With sound built as modules I get nothing on any outputs, errors from dmesg are;
dmesg | grep snd 5.206990] imx-spdif sound-spdif.13: snd_soc_register_card failed: -517 [ 5.241976] imx-spdif sound-spdif.13: snd_soc_register_card failed: -517 [ 5.258174] imx-spdif sound-spdif.13: snd-soc-dummy-dai <-> 2004000.spdif mapping ok [ 5.281704] imx-sgtl5000 sound.12: snd_soc_register_card failed (-517)
With sound built in I get sound on the 'line out' output and from dmesg;
dmesg | grep snd imx-spdif sound-spdif: snd-soc-dummy-dai <-> 2004000.spdif mapping ok
In both cases I get (or similar);
dmesg | grep firm imx-sdma 20ec000.sdma: Direct firmware load failed with error -2 imx-sdma 20ec000.sdma: loaded firmware 1.1
Not sure if the firmware message above is a problem or not.
No, it should work without loading external firmware to ram.
aplay output;
aplay -l **** List of PLAYBACK Hardware Devices **** card 0: imx6wandboardsg [imx6-wandboard-sgtl5000], device 0: HiFi sgtl5000-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: imxspdif [imx-spdif], device 0: S/PDIF PCM snd-soc-dummy-dai-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0
aplay -L null Discard all samples (playback) or generate zero samples (capture) pulse PulseAudio Sound Server sysdefault:CARD=imx6wandboardsg imx6-wandboard-sgtl5000, Default Audio Device sysdefault:CARD=imxspdif imx-spdif, Default Audio Device
aplay -vv ImABeliever.wav Playing WAVE 'ImABeliever.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo Hardware PCM card 1 'imx-spdif' device 0 subdevice 0 Its setup is: stream : PLAYBACK access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 44100 exact rate : 44100 (44100/1) msbits : 16 buffer_size : 16384 period_size : 4096 period_time : 92879 tstamp_mode : NONE period_step : 1 avail_min : 4096 period_event : 0 start_threshold : 16384 stop_threshold : 16384 silence_threshold: 0 silence_size : 0 boundary : 1073741824 appl_ptr : 0 hw_ptr : 0 ################# + | 55%
but no sound form SPDIF.
If this is right place for this and if I can be of any help debuuging or you need more info I'm more than happy to help in any way I can.
Since I sent the original message Ive realised that data is being sent to and received at the SPDIF output of the wandboard quad it can't seem to handle it.
This is somewhat unclear. If you confirm that the data is being set to spdif port correctly, what do you mean by "it can't seem to handle it" ?
If I connect a DAC to the SPDIF output and then connect the DAC to my recievers aux input I hear the sound in all it's glory.
If you have your spdif output connected to dac and that works fine then I would say your spdif is just fine. There might be something specific with your receiver.
The same receiver and cabling works with a cubietruck and the sunxi kernel.
I would suggest you hook up a scope to your spdif output for both wandboard and cubietruck and compare the signals. Perhaps the voltage levels are too low for your receiver. You might want to try another receiver, but I would check the scope outputs first.
Hope this helps.
Sinan Akman
On 24/06/2014 06:33, Sinan Akman wrote:
Hi Micheal
On 06/23/2014 02:07 PM, Michael Howard wrote:
Hello All,
I'm resending this email as orignally I wasn't subcribed and I've been told the message hasn't made it through.
I was pointed here from the Wandboard Google Groups forum. If I'm in the wrong place please accept my appologies.
With known good cabling and receiver I'm not getting sound from the Wandboard Quad's S/PDIF output.
How are you testing your spdif output exactly ?
Until now, simply from a usage point of view with alsa. That is to say aplay, the same as with the cubietruck.
I have built various kernels from mainline, the last two sources I tried are 3.15.1 and 3.16-rc2.
With sound built as modules I get nothing on any outputs, errors from dmesg are;
dmesg | grep snd 5.206990] imx-spdif sound-spdif.13: snd_soc_register_card failed: -517 [ 5.241976] imx-spdif sound-spdif.13: snd_soc_register_card failed: -517 [ 5.258174] imx-spdif sound-spdif.13: snd-soc-dummy-dai <-> 2004000.spdif mapping ok [ 5.281704] imx-sgtl5000 sound.12: snd_soc_register_card failed (-517)
With sound built in I get sound on the 'line out' output and from dmesg;
dmesg | grep snd imx-spdif sound-spdif: snd-soc-dummy-dai <-> 2004000.spdif mapping ok
In both cases I get (or similar);
dmesg | grep firm imx-sdma 20ec000.sdma: Direct firmware load failed with error -2 imx-sdma 20ec000.sdma: loaded firmware 1.1
Not sure if the firmware message above is a problem or not.
No, it should work without loading external firmware to ram.
I thought so with current mainline.
aplay output;
aplay -l **** List of PLAYBACK Hardware Devices **** card 0: imx6wandboardsg [imx6-wandboard-sgtl5000], device 0: HiFi sgtl5000-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: imxspdif [imx-spdif], device 0: S/PDIF PCM snd-soc-dummy-dai-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0
aplay -L null Discard all samples (playback) or generate zero samples (capture) pulse PulseAudio Sound Server sysdefault:CARD=imx6wandboardsg imx6-wandboard-sgtl5000, Default Audio Device sysdefault:CARD=imxspdif imx-spdif, Default Audio Device
aplay -vv ImABeliever.wav Playing WAVE 'ImABeliever.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo Hardware PCM card 1 'imx-spdif' device 0 subdevice 0 Its setup is: stream : PLAYBACK access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 44100 exact rate : 44100 (44100/1) msbits : 16 buffer_size : 16384 period_size : 4096 period_time : 92879 tstamp_mode : NONE period_step : 1 avail_min : 4096 period_event : 0 start_threshold : 16384 stop_threshold : 16384 silence_threshold: 0 silence_size : 0 boundary : 1073741824 appl_ptr : 0 hw_ptr : 0 ################# + | 55%
but no sound form SPDIF.
If this is right place for this and if I can be of any help debuuging or you need more info I'm more than happy to help in any way I can.
Since I sent the original message Ive realised that data is being sent to and received at the SPDIF output of the wandboard quad it can't seem to handle it.
This is somewhat unclear. If you confirm that the data is being set to spdif port correctly, what do you mean by "it can't seem to handle it" ?
I probably should have phrased this as 'data arrives at the SPDID output but is not understood at the receiver'? The cubietruck manages this task though with the same data, same commands so the two SPDIF outputs are doing somethin differently? Or am I being to simplistic? :)
If I connect a DAC to the SPDIF output and then connect the DAC to my recievers aux input I hear the sound in all it's glory.
If you have your spdif output connected to dac and that works fine then I would say your spdif is just fine. There might be something specific with your receiver.
The same receiver and cabling works with a cubietruck and the sunxi kernel.
I would suggest you hook up a scope to your spdif output for both wandboard and cubietruck and compare the signals. Perhaps the voltage levels are too low for your receiver. You might want to try another receiver, but I would check the scope outputs first.
Ok, I'll 'hook up a scope' and get back to the list but I am a complete amateur :) I have tried a second receiver and the results are the same, as in, the wandboard fails, the cubietruck works. I fear that this a design issue and I'm wasting your time.
Cheers Mike.
Hi Mike
I have tried a second receiver and the results are the same, as in, the wandboard fails, the cubietruck works. I fear that this a design issue and I'm wasting your time.
There is one another thing. When you run aplay for testing I suggest you define the format and the rate explicitly and don't use plugin as part of your device. It is possible that your default format that your aplay on wandbord picks is not compatible with what your receiver can handle.
Regards
Sinan Akman
On 25/06/2014 00:49, Sinan Akman wrote:
Hi Mike
I have tried a second receiver and the results are the same, as in, the wandboard fails, the cubietruck works. I fear that this a design issue and I'm wasting your time.
There is one another thing. When you run aplay for testing I suggest you define the format and the rate explicitly and don't use plugin as part of your device. It is possible that your default format that your aplay on wandbord picks is not compatible with what your receiver can handle.
Regards
Sinan Akman
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Hi Sinan,
Well I've tried all the formats and various rates without suceess.
I've determined the capabilities of the Wandboard spdif to be;
alsacap -d hw:0,0 *** Exploring configuration space of device `hw:0,0' for playback *** 2 channels Sampling rate 32000..48000 Hz Sample formats: S16_LE, S24_LE
as opposed to the Cubietruck (which works - as does Win7);
alsacap -d hw:1,0 *** Exploring configuration space of device `hw:1,0' for playback *** 1..2 channels Sampling rate 8000..192000 Hz Sample formats: S16_LE Significant bits: 16
The ouputs of speaker test are almost identical;
Wnadboard;
speaker-test -Dsysdefault:CARD=imxspdif -c2
speaker-test 1.0.25
Playback device is sysdefault:CARD=imxspdif Stream parameters are 48000Hz, S16_LE, 2 channels Using 16 octaves of pink noise Rate set to 48000Hz (requested 48000Hz) Buffer size range from 64 to 16384 Period size range from 32 to 8192 Using max buffer size 16384 Periods = 4 was set period_size = 4096 was set buffer_size = 16384
Cubietruck;
speaker-test -Dsysdefault:CARD=sunxisndspdif -c2
speaker-test 1.0.25
Playback device is sysdefault:CARD=sunxisndspdif Stream parameters are 48000Hz, S16_LE, 2 channels Using 16 octaves of pink noise Rate set to 48000Hz (requested 48000Hz) Buffer size range from 4096 to 32768 Period size range from 1024 to 8192 Using max buffer size 32768 Periods = 4 was set period_size = 8192 was set buffer_size = 32768
One obvious difference is that the Wandboard uses 'snd-soc-dummy-dai'.
I'll get a scope on the job this evening, is there anything inparticular I should be looking for?
Cheers, Mike.
On 25/06/2014 15:16, Michael Howard wrote:
On 25/06/2014 00:49, Sinan Akman wrote:
Hi Mike
I have tried a second receiver and the results are the same, as in, the wandboard fails, the cubietruck works. I fear that this a design issue and I'm wasting your time.
There is one another thing. When you run aplay for testing I suggest you define the format and the rate explicitly and don't use plugin as part of your device. It is possible that your default format that your aplay on wandbord picks is not compatible with what your receiver can handle.
Regards
Sinan Akman
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Hi Sinan,
Well I've tried all the formats and various rates without suceess.
I've determined the capabilities of the Wandboard spdif to be;
alsacap -d hw:0,0 *** Exploring configuration space of device `hw:0,0' for playback *** 2 channels Sampling rate 32000..48000 Hz Sample formats: S16_LE, S24_LE
as opposed to the Cubietruck (which works - as does Win7);
alsacap -d hw:1,0 *** Exploring configuration space of device `hw:1,0' for playback *** 1..2 channels Sampling rate 8000..192000 Hz Sample formats: S16_LE Significant bits: 16
The ouputs of speaker test are almost identical;
Wnadboard;
speaker-test -Dsysdefault:CARD=imxspdif -c2
speaker-test 1.0.25
Playback device is sysdefault:CARD=imxspdif Stream parameters are 48000Hz, S16_LE, 2 channels Using 16 octaves of pink noise Rate set to 48000Hz (requested 48000Hz) Buffer size range from 64 to 16384 Period size range from 32 to 8192 Using max buffer size 16384 Periods = 4 was set period_size = 4096 was set buffer_size = 16384
Cubietruck;
speaker-test -Dsysdefault:CARD=sunxisndspdif -c2
speaker-test 1.0.25
Playback device is sysdefault:CARD=sunxisndspdif Stream parameters are 48000Hz, S16_LE, 2 channels Using 16 octaves of pink noise Rate set to 48000Hz (requested 48000Hz) Buffer size range from 4096 to 32768 Period size range from 1024 to 8192 Using max buffer size 32768 Periods = 4 was set period_size = 8192 was set buffer_size = 32768
One obvious difference is that the Wandboard uses 'snd-soc-dummy-dai'.
I'll get a scope on the job this evening, is there anything inparticular I should be looking for?
Cheers, Mike.
I've used a scope on both the CT & WB but it didn't shed any light on the matter. Voltages are as advertised (which maybe the problem) and there is very little difference between the frequencies of the two boards or how the wave looks. Frequencies are approx 1.78MHz for the Cubietruck and approx 1.8MHz for the wandboard.
The volatges match the spec sheets, i.e. 5v for the Cubietruck and 3.3v for the Wandboard at VCC whether audio is playing or not.
So unless both my receivers have a problem with only 3.3v I'm at a loss. I can't find anything on the limited specs for the receivers relating to this.
I guess I'll just sideline the Wandboards and use proper kit instead. I can still compile on them, until they overheat :)
Cheers, Mike.
Hi Mike, I just saw this after I sent my other e-mail.
The volatges match the spec sheets, i.e. 5v for the Cubietruck and 3.3v for the Wandboard at VCC whether audio is playing or not.
Yes, this might be the issue.
So unless both my receivers have a problem with only 3.3v I'm at a loss. I can't find anything on the limited specs for the receivers relating to this.
I think you can just test your receiver(s) with another 3.3v source and if you see the same problem then they probably need 5v levels.
I guess I'll just sideline the Wandboards and use proper kit instead.
If it turns out that the voltage level is really the problem and you need to use those receivers I guess this would be the case. I am not electrical but you might be able to build a small adaptor to change the voltage levels on the spdif output. This would be another solution.
Regards
Sinan Akman
Hi Mike
One obvious difference is that the Wandboard uses 'snd-soc-dummy-dai'.
What does the other board show ?
I'll get a scope on the job this evening, is there anything inparticular I should be looking for?
I am not an expert on spdif electrical levels but at one one point I was explained that professional grade cd players might have higher signal level (as I was using spdif as input). So perhaps you can compare the signal levels of the two different boards and see if there is a visible difference there.
Also, I don't read the mailing list regularly so you might want to cc your replies to me if you want me see them sooner.
Hope this helps
Sinan Akman
participants (2)
-
Michael Howard
-
Sinan Akman