OpenELEC Testbuilds for RaspberryPi Part 3 (Kodi 14.0) - Printable Version +- Kodi Community Forum (https://forum.kodi.tv) +-- Forum: Support (https://forum.kodi.tv/forumdisplay.php?fid=33) +--- Forum: General Support (https://forum.kodi.tv/forumdisplay.php?fid=111) +---- Forum: Raspberry Pi (https://forum.kodi.tv/forumdisplay.php?fid=166) +---- Thread: OpenELEC Testbuilds for RaspberryPi Part 3 (Kodi 14.0) (/showthread.php?tid=192380) Pages:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
|
RE: OpenELEC Testbuilds for RaspberryPi Part 3 - popcornmix - 2014-09-24 (2014-09-24, 15:16)plugh Wrote: Can't comments on all your cases, but the bcm2835 driver (both analog and hdmi) does not declare support for S24_LE Actually xbmc doesn't use alsa for hdmi/analogue outputs. It uses openmax directly (and does support 8/16/24/32/float audio formats). Internally xbmc uses ffmpeg's libswresample for format conversion. However the Pi has a GPU accelerated path for this which means libswresample is not used. I did suspect that the GPU path might have a bug with 24-bit formats, but I get get the same noise with the GPU accelerated path disabled. This fact suggests the bug is not in ffmpeg's libswresample as I believe I'm seeing it with that path disabled Note there are two examples of noise produced: One when using HifiBerry, presumably with mostly float audio (the output of most of ffmeg's audio decoders) . This will probably exercise a float->S24_LE conversion. One when using s24_le.wav with HDMI audio output. This will probably exercise a S24_LE->float conversion (I'll have to check exactly what AudioEngine chooses for the sink in this case). Possibly there are two bugs. One is a general disagreement about where bytes go in a S24 WAV file. The other is on the path from xbmc->hifiberry driver does something wrong with S24. RE: OpenELEC Testbuilds for RaspberryPi Part 3 - plugh - 2014-09-24 BTW, the S24_LE file I supplied is slightly 'wrong'. I discovered the alsa plugin stack I'm using (to boost volume) apparently sign-extends the 24 bit data (alsa plugin bug?). It should not matter, as S24_LE consumers are supposed to ignore the high byte. However for accuracies sake, attached is an unprocessed (even quieter) S24_LE sample. RE: OpenELEC Testbuilds for RaspberryPi Part 3 - popcornmix - 2014-09-24 (2014-09-24, 15:46)plugh Wrote: BTW, the S24_LE file I supplied is slightly 'wrong'. I discovered the alsa plugin stack I'm using (to boost volume) apparently sign-extends the 24 bit data (alsa plugin bug?). It should not matter, as S24_LE consumers are supposed to ignore the high byte. However for accuracies sake, attached is an unprocessed (even quieter) S24_LE sample. This now now plays as noise with everything (including audacity). Audacity is now full range. Looks like left channel is white noise and right channel is doing some chirping that looks like it is clipped. RE: OpenELEC Testbuilds for RaspberryPi Part 3 - plugh - 2014-09-24 Yes, only one channel of real data (it's a mono mic), other channel all zeros. That is an interesting result. In a post in RaspberryPi forum, I noted that the i2s hardware was capable of doing sign extension for non-16/32 bit capture, and was a trivial change. (Edit one line in i2s driver - nobody commented) But since (by definition, as I understand it) the contents of the high byte should be immaterial I didn't pursue it. Where do you want to go from here? My interest was in establishing whether there was a bug in the driver(s) and/or hardware, which I'd say the aplay test answered (no), and whether an alsa config file might offer an alternative to killing support in the drivers for problematic software (awaiting boberze). You are obviously more knowledgeable about the higher level audio paths. Is there anything else I can contribute to the problem analysis at this point? RE: OpenELEC Testbuilds for RaspberryPi Part 3 - popcornmix - 2014-09-24 (2014-09-24, 16:31)plugh Wrote: Yes, only one channel of real data (it's a mono mic), other channel all zeros. But it isn't according to Audacity. The file looks like: RE: OpenELEC Testbuilds for RaspberryPi Part 3 - plugh - 2014-09-24 Hexdump the file. All zeroes in one channel. (I'd really like to get that 'mono' patch in i2s driver - hint hint) BTW, what do you think - Should I pursue the 'sign-extend' thing, too? We apparently have some software 'out there' that thinks S24_LE should be sign-extended into high byte... Edit: Your comment about 'white noise' in left channel - that's ambient background, I wasn't speaking during that capture. I can supply one with me speaking, if you want. RE: OpenELEC Testbuilds for RaspberryPi Part 3 - popcornmix - 2014-09-24 (2014-09-23, 23:24)Unfledged Wrote: Short sample here, and if there's anything else I can provide to help track down the issue, let me know. I've pushed a fix for this file. Please test in next build. RE: OpenELEC Testbuilds for RaspberryPi Part 3 - BoBeRzE - 2014-09-24 (2014-09-24, 13:32)plugh Wrote: Look at the last line of the release announcement post. That is what changed. Hi, all my test are done with Milhouse build #0922 1. destroyed sound in xbmc 3. with Code: pcm.!default { i get destroyed sound in xbmc and with aplay i get the following output. Code: OpenELEC:~ # aplay -vv -D default /storage/music/s24_le.wav With Code: pcm.!default { i get destroyed sound in xbmc and with aplay i get the following output but no sound Code: OpenELEC:~ # aplay -vv -D default /storage/music/s24_le.wav With format S32_LE in "asound.conf" the some behavior like above. PS: I did every time a restart after change the "asound.conf" PPS: i hope you can read/understand my bad english Please let me know if i can test another thing for you. Thank you EDIT: I just played around with the asound.conf and i see its not necessary to reboot the Pi after i change something. After i renamed the file i was able to play your file again with aplay (no reboot). I think when i restart xbmc with 'systemctl restart xbmc' it use also the new asound.conf. Is that right? RE: OpenELEC Testbuilds for RaspberryPi Part 3 - danny_ice - 2014-09-24 hi, is anyone else having a problem with the latest builds when using dvdplayer? video is stuttering and with no audio, if I pause playback for a few seconds the stuttering goes away but there is still no sound. All is fine when using omx player. the last build where everything works okay for me is #0918b, 18-Sep-2014 Cheers Dan RE: OpenELEC Testbuilds for RaspberryPi Part 3 - plugh - 2014-09-24 (2014-09-24, 20:20)BoBeRzE Wrote: Hi, Quote:OOPS - those config file incantations can be black magic it should have been Code: pcm.!default { Code: pcm.!default { Quote:EDIT: I just played around with the asound.conf and i see its not necessary to reboot the Pi after i change something. After i renamed the file i was able to play your file again with aplay (no reboot). I think when i restart xbmc with 'systemctl restart xbmc' it use also the new asound.conf. Is what right?Yes, restarting application should be enough to cause alsa to reread file (in most cases). and thanks again for your efforts, it is helping to pin things down. RE: OpenELEC Testbuilds for RaspberryPi Part 3 - popcornmix - 2014-09-24 (2014-09-24, 20:20)danny_ice Wrote: is anyone else having a problem with the latest builds when using dvdplayer? video is stuttering and with no audio, if I pause playback for a few seconds the stuttering goes away but there is still no sound. All is fine when using omx player. the last build where everything works okay for me is #0918b, 18-Sep-2014 Can you describe your playback settings? Can you try changing "sync playback to display" and the 4 "A/V Sync methods" RE: OpenELEC Testbuilds for RaspberryPi Part 3 - BoBeRzE - 2014-09-24 Hello, both variants of your asound.conf give me the same. No sound with aplay and a destroyed sound in xbmc. But i have change the asound.conf as follow. I added device 0 Code: pcm.!default { now i get Code: OpenELEC:~ # aplay -v --device=default /storage/music/s24_le.wav with "format s24_le" in the asound.conf i kann play the file with "aplay" but still nois in xbmc. RE: OpenELEC Testbuilds for RaspberryPi Part 3 - danny_ice - 2014-09-24 (2014-09-24, 21:01)popcornmix Wrote:(2014-09-24, 20:20)danny_ice Wrote: is anyone else having a problem with the latest builds when using dvdplayer? video is stuttering and with no audio, if I pause playback for a few seconds the stuttering goes away but there is still no sound. All is fine when using omx player. the last build where everything works okay for me is #0918b, 18-Sep-2014 thanks for the quick reply, I have just figured it out, for some reason when I upgraded to the latest nightly it switched the sync method to audio clock. i've changed it back to video clock - resample audio, and it is now working fine Cheers Dan RE: OpenELEC Testbuilds for RaspberryPi Part 3 - plugh - 2014-09-24 (2014-09-24, 21:11)BoBeRzE Wrote: Hello,duh - In my defense I'll say that isn't always needed What happens with xbmc with that config (and also with s32_le in that config)? RE: OpenELEC Testbuilds for RaspberryPi Part 3 - popcornmix - 2014-09-24 (2014-09-24, 21:12)danny_ice Wrote: thanks for the quick reply, I have just figured it out, for some reason when I upgraded to the latest nightly it switched the sync method to audio clock. i've changed it back to video clock - resample audio, and it is now working fine Audio clock is still working okay for me. If you switch back to "audio clock" is it still broken? I wonder if somehow it wasn't actually on "audio clock", but was just displaying that as it had internally got an invalid setting? |