OpenELEC Testbuilds for RaspberryPi Part 2 - 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 2 (/showthread.php?tid=184866) 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
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
|
RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Milhouse - 2013-12-14 (2013-12-14, 20:51)popcornmix Wrote: It should apply to newclock3, but you probably want to remove "[rbp] Add support for gui sounds to PiAudio backend" which may conflict. With the above commit removed, applying piaudio_sink on top of newclock3 still fails due to a conflict with "[rbp/omxplayer] Remove visualisation support". It's possible to build without both of these patches, would you expect any problems? The piaudio_sink branch could do with being rebased/resynced as several of FernetMentas commits have now appeared in xbmc/master. I'll upload a combined build shortly. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - popcornmix - 2013-12-14 (2013-12-14, 21:10)MilhouseVH Wrote: With the above commit removed, applying piaudio_sink on top of newclock3 still fails due to a conflict with "[rbp/omxplayer] Remove visualisation support". It's possible to build without both of these patches, would you expect any problems? Not removing visualisation support will be harmless (if paplayer handles audio files, then the visualisation from omxplayer won't be called). I've rebased piaudio_sink. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Leopold - 2013-12-14 (2013-12-14, 18:00)robby1337 Wrote: That doesnt work, no SMB here You might find it easier to use this http://openelec-dev-update.googlecode.com/ RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Milhouse - 2013-12-14 New OpenELEC Gotham build: #1412b (obsolete) Code: rpi512:~ # uname -a Based on tip of XBMC master (d886d3cc40) and tip of OpenELEC master (5bab247229) with the following modifications:
@popcornmix: A quick test with Flac audio shows that gapless playback is almost working perfectly, however there's a very brief (sub-second) silence between tracks, is this expected/known? I've also noticed that "rewind" is working correctly - maybe due to the switch to paplayer? Good news anyway! RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Milhouse - 2013-12-14 I also note that enabling "debugging", and then playing a song seems to load the CPU considerably (up to 60% from average 30% on a 1GHz Pi), and seems to be responsible for frequent but brief pauses (stutter) to the audio output. Without debugging, there are no pauses/stutter. I can't see anything obvious in the debug log that coincides with each stutter - just a *lot* of the following: Code: 19:58:06 1374.082153 T:2842686544 DEBUG: PAPlayer::Process - freeBufferTime=0.00 RE: OpenELEC Testbuilds for RaspberryPi Part 2 - popcornmix - 2013-12-14 (2013-12-14, 21:59)MilhouseVH Wrote: I also note that enabling "debugging", and then playing a song seems to load the CPU considerably (up to 60% from average 30% on a 1GHz Pi), and seems to be responsible for frequent but brief pauses (stutter) to the audio output. Without debugging, there are no pauses/stutter. I can't see anything obvious in the debug log that coincides with each stutter - just a *lot* of the following:Yes, that is unnecessary. Removed now, RE: OpenELEC Testbuilds for RaspberryPi Part 2 - popcornmix - 2013-12-14 (2013-12-14, 21:47)MilhouseVH Wrote: @popcornmix: A quick test with Flac audio shows that gapless playback is almost working perfectly, however there's a very brief (sub-second) silence between tracks, is this expected/known? No, but we did find a number of cases where high cpu caused underrun. You may see "underrun" in log if Pi Sink underruns, but you also get silence inserted when engine underruns without a message. One issue is that the Sink thread is meant to run at higher (nice=-1) priority than other threads but that may not be allowed. On raspbian I had to insert Code: * - nice -1 In OpenELEC I'm not sure if processes are allowed to decrease their nice level. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Milhouse - 2013-12-14 (2013-12-14, 22:26)popcornmix Wrote: Yes, that is unnecessary. Removed now, Thanks, I've uploaded a new build #1412b (see post #1894) with this reduced logging. (2013-12-14, 22:31)popcornmix Wrote: No, but we did find a number of cases where high cpu caused underrun. You may see "underrun" in log if Pi Sink underruns, but you also get silence inserted when engine underruns without a message. Not sure about decreasing the nice level in OpenELEC, though as everything runs as root I don't see why you shouldn't be able to do that. In case its useful, this is the debug that appears when one Flac track ends and the next begins - there is a brief silence during the transition (CPU load averages about 25% at this time): Code: 21:03:15 706.736511 T:2716849232 DEBUG: OnQueueNextItem : play state was 2, starting 0 RE: OpenELEC Testbuilds for RaspberryPi Part 2 - popcornmix - 2013-12-14 (2013-12-14, 23:01)MilhouseVH Wrote: In case its useful, this is the debug that appears when one Flac track ends and the next begins - there is a brief silence during the transition: Seems to be closing and opening Sink. That may be down to settings. You want "crossfade between songs" to be set to something (e.g. 5s) in settings/music/playback. And in system/audio output you want optimised (I think best match stops crossfade working). I'd recommend trying with Low for resample quality if you are seeing problems (although it doesn't make that much difference to cpu). RE: OpenELEC Testbuilds for RaspberryPi Part 2 - ph87 - 2013-12-14 Edit: Sorry wrong thread!!! RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Milhouse - 2013-12-14 (2013-12-14, 23:16)popcornmix Wrote: Seems to be closing and opening Sink. That may be down to settings. Ah yes, a cross-fade of 5 seconds does...a cross-fade! However this isn't quite the same as non-crossfaded "gapless" playback, since the cross-fade is fairly obvious and not entirely desirable. A value of 1-4 seconds cross-fade still results in brief-silence, and the 5 second cross-fade eliminates this silence, but the resulting cross-faded audio isn't what I would consider to be quite the same as purely "gapless" playback where the two tracks continue seamlessly, with no fade or interruption. I don't mean to sound ungrateful, as in general it's a big improvement, but cross-fading as a solution isn't really appropriate on most gapless tracks (IMHO). I think given the choice, I would accept the very brief silence rather than the cross-fade so that I can listen to the tracks as they were intended to be heard (and no I'm not an audiophile but just realised I might actually be sounding like one! ) RE: OpenELEC Testbuilds for RaspberryPi Part 2 - popcornmix - 2013-12-14 (2013-12-14, 23:37)MilhouseVH Wrote: Ah yes, a cross-fade of 5 seconds does...a cross-fade! However this isn't quite the same as non-crossfaded "gapless" playback, since the cross-fade is fairly obvious and not entirely desirable. How about changing optimised to fixed? Does "keep receiver alive" help? RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Milhouse - 2013-12-14 (2013-12-14, 23:42)popcornmix Wrote: How about changing optimised to fixed? "Fixed" appears to have increased the duration of the silence between tracks from ~0.1 second to somewhere between 0.5 second and 1 second. The silence is usually heard between 5 and 2 seconds before the end of each track (this is with both Optimised and Fixed). "Keep audio device alive" didn't help with either "Fixed" or "Optimised" settings, but then I'm not connecting to a receiver (HDMI 2.0 to monitor with stereo line-out from monitor to the line-in on a PC). Edit: Looking at the time code and comparing it with when the silence occurs, these tracks are being played back in what I would consider to be a "gapless" manner, as there is no gap *between* each track. The actual silence is occurring between 5 and 2 seconds *before* the end of each track. So the gapless side of things seems to be sorted, I guess it's this closing and opening of the sink (which may be what happens a few seconds before the end of each track) that is the remaining problem and prevents the audio from being totally seamless/continuous. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - User 180998 - 2013-12-15 (2013-12-14, 13:14)MilhouseVH Wrote:(2013-12-14, 12:47)webjib Wrote: Just to let you know I've got a bug with USB drive attached to the Pi with recent MilHouseVH version. The drive is mounted, but partially, this is weird. Only the first folder of my USB drive is available (SAMBA or SSH). Here's the log : http://xbmclogs.com/show.php?id=97478 Can't find anything about USB mount in the log ?! By the way, the issue is still the same with build from today. When I re-plug my USB drive, I've got usual notification in xbmc (drive mounted) but the drive does not appear in filemanager as well. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Trickname - 2013-12-15 If you have this: Quote:For me some LiveTvChannels only shows black screen, try this: 1. System-System 2. Set Gui resolution limt 720 |