Rockbox

I'm willing to bet 4 internets that your voice file is out dated. update it and try again

Hi,

Unfortunately its not so.

I used the daily voice file from this morning and the rockbox simulator (sansa clip plus) because i left my player in the office.

The following can be seen:
- in the voice settings are some other settings and words which souldn't be there
- the rockbox info window reports some weird things including a few lines of nothing
- not all files and folders where spoken


Is the build server having issues building correct voices or is the internal voice UI having issues?

Could someone check that out?
Its reproduceable.

Greetings,
Simon

Simulators need their own voice files generating - they aren't compatible with device voice files, sadly.

Sorry guys. but there is really something broken. also tested with todays rockbox build including voice file of todays build from the server.
Would someone have mercy and do a little research?
- the micro sd card folder is not spoken and various other files .
- the rockbox info screen isn't spoken anymore. in version 3.8.1 all things are working great.
maybe you will find more things.
tested on platform sansa clip+

This should really be taken to the support channels (forum, iRC, mailing list) for a bit of diagnosis at this point.

Here's a patch which fixes both problems. I'm not sure why the pcm_play_start() was in the place it was previously, but it looked odd and didn't always get called. PCM experts - please check!

Unfortuately I don't have the right cross compilers installed to produce a Clip+ build at the moment; if you can't build one yourself, post back and I'll see if I can get it working.

Hello.

I also confirmed this big bug in voicing of menus.

Today a make hard more tests on Sansa Fuze 2 and Sansa Clip+ .
I install last daily build of RB over RBUtil 1.2.10 and make Czech voice, next install over RBUtil 1.2.7 and make Czech voice - same situation.
I install RB 3.8.1 over RBUtil 1.2.10 and make Czech voice and work good.
I next steps I testing builds from date 24.4.2011 to 18.5. and i found change about date 26.4. and 27.4.
last good working build is r29784 - 26th Apr 21:30.
From next r29785 - 27th Apr 03:08 http://svn.rockbox.org/viewvc.cgi?view=rev;revision=29785
there are described errors in Voice UI.

Please correct it someone as soon as possible.
Much more thanks from me and for all visually impaired people (my blind friends and colleagues).

Last working build for Fuze2 http://download.rockbox.org/daily/sansafuzev2/rockbox-sansafuzev2-20110427.zip
and for Clip+ http://download.rockbox.org/daily/sansaclipplus/rockbox-sansaclipplus-20110427.zip

@Steve (pondlife):

Any idea just why anything should have changed in r29785 with regards to voice when it should have stayed clear of that? voice_thread.c is still five months old. It's not like I didn't run voice checks during the development, yet perhaps not on the right targets.

But really from then on it has those problems.

I found that in  FS#12069  was little change in voice_thread.h but in commit r29785 http://svn.rockbox.org/viewvc.cgi?view=rev;revision=29785
not included. I don't know if problem may be here.

Here is :

Index: apps/voice_thread.h
===================================================================
--- apps/voice_thread.h (revision 29783)
+++ apps/voice_thread.h (working copy)
@@ -31,5 +31,6 @@
void voice_thread_init(void);
void voice_thread_resume(void);
void voice_thread_set_priority(int priority);
+void voice_wait(void);

#endif /* VOICE_THREAD_H */

@MikeS - I've no idea and hoped you'd understand it better. The voice_thread.c code is a bit odd in general, any chance it was working by luck more than judgement?

What it's doing and how it works is quite deliberate.

But, could the call to audio_pcmbuf_may_play may be causing the problem. That was changed to service playback properly (by avoiding improper starts) and may be the reason because if playback isn't going, the pcm buffer will fill and not auto start when it hits the watermark. This will lead to a full buffer with no playback and the voice won't be able to finish inserting because PCM won't get used up to clear space for the rest. My guess is the voice thread will be stuck in *R state indefinitely until a message interrupts it and either stops it or a clip that fits (or concatenated clips that fit) entirely into the 1-second PCM buffer is/are played.

Check it out in the OS Stacks menu when it happens.

Hmmm....it looks safe to change the check in audio_pcmbuf_may_play (playback.c) to be:

play_status != PLAY_PAUSED && !ff_rw_mode;

@MikeS - That fixes it, please commit if you're happy it's safe.