[eckythump]

I'll try and do a little more diagnostic testing this afternoon.

The http server will lend itself well to this. I'm going to hack in some code so it'll ignore the text variable and just spit out a slightly longer string each time. I'll add the wav file size to the logging output and see if I can't find the approximate point where it crosses from okay and into crash land.

One interesting thing I noticed also was a couple of spoken things had the end cut off. I copied the .wav back to another machine to listen and the wav was complete, so it was xbmc doing something weird there, too. I will see if I can sus that out in my testing, too.

Will let you know how I go...

Oh, and I tried one of Milhouse's nightly builds from April 23, and it still has the same crashing behaviour in it. Unfortunately, OpenELEC doesn't have gdb handy so I can't attach to xbmc.bin and see what's going on when it crashes. If you're able to get raspbmc going with a recent enough version that crashes, it might be a good place to start if we can't find any obvious bugs.

[eckythump]

Okay, I did some diagnostics to see what I could sus out.

No idea if this will prove to be of any value, but here's what I've determined so far:

The wav files play fine up until around 36000 bytes, and after that they start to get truncated. I can't hear truncation on a 35941 byte wav, but can on a 37102 byte one.

They'll then continue to play, albeit truncated up to about the 49000 byte mark where they crash xbmc.

The largest wav that I saw play without crashing was 48326 bytes. It was truncated, but didn't crash. The smallest wav I've seen crash xbmc was 48872 bytes.

So again, no idea if the specific numbers above are of any value, but I can say now with extremely high confidence that it's definitely related to the length of the wav files being played.

[Traker1001]

This is wonderful, I want to offer my most heartfelt appreciation to you folks. I would like to do everything I can to help everyone out. Really Really happy to see this.

Something small I found out, though, I have been using the quartz skin and trying to simplify things. One of the things I did was delete movies category and rename the TV Shows category to Videos in effort to more or less combine the 2 into a single category on the menu. Well After I renamed the TV Shows to Category, It shows Videos on the screen, But still reads TV shows. Is there an XML File I need to change to get it to read as Just Videos or am I missing something?

Also, when you go into a list of items, Is there a way of counting the list of items and having it read the number of available selections in the list when you go into a list. So for example I go into movies list and I have 52 items, It says 52 items so I general idea of how large the list is.

I will be loading OpenElec and the Httpd onto a intel NUC that I have to see if I can help you guys out on some of the testing. Do you think my Celeron Nuc with 2gb ram can handle the speech and the xbmc. I would think, since the pi is capable of it, but then again pi is completely different architecture. Would it be better for me to test Openelec Gotham or Frodo? I have been generally sticking to Gotham since they are so painfully close to public release.

@edit
Just a thought, At least with a X86 architecture, I wonder if some like this Sapi/Wine see: http://code.google.com/p/open-sapi Combo wouldn't be better and more stable than running a Httpd setup? Not that i know if the sapi/wine is even stable in the first place.

@edit
I also came across this which is fascinating.
https://www.cepstral.com/forums/viewtopi...=2&t=84724
And the Demo voice http://www.cepstral.com/en/demos

[eckythump]

Something small I found out, though, I have been using the quartz skin and trying to simplify things. One of the things I did was delete movies category and rename the TV Shows category to Videos in effort to more or less combine the 2 into a single category on the menu. Well After I renamed the TV Shows to Category, It shows Videos on the screen, But still reads TV shows. Is there an XML File I need to change to get it to read as Just Videos or am I missing something?

You probably want to look at the sources.xml file. On my system it is found at /storage/.xbmc/userdata/sources.xml

I set my video sources up once and forgot about them, so I am not sure how one would go about doing what you want via the GUI, but the sources.xml file lets you specify multiple sources for a given name, like so:

Code:

<source>
    <name>TV Shows</name>
    <path pathversion="1">/storage/tvshows/</path>
    <path pathversion="1">smb://HAPPYSAMBA/media/video/TV/</path>
</source>

It sounds like you might just need to edit the name of a source and perhaps move some <path> elements from one source into another. Be aware your changes probably won't take affect until you restart xbmc.

I will be loading OpenElec and the Httpd onto a intel NUC that I have to see if I can help you guys out on some of the testing. Do you think my Celeron Nuc with 2gb ram can handle the speech and the xbmc. I would think, since the pi is capable of it, but then again pi is completely different architecture. Would it be better for me to test Openelec Gotham or Frodo? I have been generally sticking to Gotham since they are so painfully close to public release.

I'm sure the NUC will run xbmc and handle speech just fine. It may choke on HD video, but for the XBMC GUI, I'd be very surprised if it even breaks a sweat.

I'd go for Gotham, too.

Also, you said you'd be loading the httpd onto the NUC. I think you may be confused about this particular speech backend. For this backend, there are two separate components. There's the "ttsd" backend that you select from the XBMC TTS configuration section as the default TTS engine, and then there's the server "httpttsd" that you run on a windows computer on your local network. The ttsd backend sends the text to the server, tells it the voice and speed to use, and it sends back a wav file for XBMC TTS to play.

Just a thought, At least with a X86 architecture, I wonder if some like this Sapi/Wine see: http://code.google.com/p/open-sapi Combo wouldn't be better and more stable than running a Httpd setup? Not that i know if the sapi/wine is even stable in the first place.

That is an interesting project, but it sounds like it's not as stable as they'd like yet. Given it hooks into the gnome speech dispatcher, and that's already a supported backend for XBMC TTS, there's (theoretically) nothing stopping people using it now if they have the time and patience to set it up.

httpttsd hasn't had any stability problems for me, so far, but I literally only wrote it a couple of weeks ago, so it's still new and needs wider testing, but it's pretty basic and I don't foresee any major issues.

As for "better", that ultimately would come down to your personal home setup. For me, since I have a windows machine on the same network running 24/7, it's probably better to run httpttsd on it and use that. If I just had a linux box running XBMC, then sapi for wine would probably be better than running a virtual windows machine on the same server just to run httpttsd.

I also came across this which is fascinating.
https://www.cepstral.com/forums/viewtopi...=2&t=84724
And the Demo voice http://www.cepstral.com/en/demos

I saw that, too. I was contemplating contacting them to see if I could get a trial copy of that voice to create a backend for it, but haven't gotten around to it. I've used Cepstral voices before and they provide a simple command line utility called "swift", so creating a new backend for it should be fairly trivial as it'd differ very little from existing backends like flite, espeak and pico2wave.

Good luck with the NUC. Please don't hesitate to let me know if you notice any bugs or other issues with the httpttsd server.

[ruuk]

Added a new version to my repository: 0.0.44.

Get it or the repository from the Downloads Page.

Changes:

• Added Cepstral backend
  
• Added speaking number of items for lists
  
• Divided settings into 'Engine', 'Options' and 'Advanced' sections
  
• Added 'Speak Number Of Items For Lists' to Settings::Options
  
• Fix HTTP wav server backend to work properly with perl server again
  

---

This is wonderful, I want to offer my most heartfelt appreciation to you folks. I would like to do everything I can to help everyone out. Really Really happy to see this.

Thanks

Also, when you go into a list of items, Is there a way of counting the list of items and having it read the number of available selections in the list when you go into a list. So for example I go into movies list and I have 52 items, It says 52 items so I general idea of how large the list is.

Added in the new version.

I also came across this which is fascinating.
https://www.cepstral.com/forums/viewtopi...=2&t=84724
And the Demo voice http://www.cepstral.com/en/demos

Hmmm.... that is interesting. Maybe I'll add a backend for that - whoops I already did
This has only been tested on linux, plus I didn't purchase licenses for any of the voices so I had to listen to "This voice is not licensed. Please go to..." at the begining of each phrase, so it was hard to judge performance. It should work fine though. Currently, you can select from available voices, but you can't set rate or anything.

[ruuk]

I'll have to modify the Cepstral backend to allow for using aoss like the forum post about the Raspberry Pi. That should be simple.

[popcornmix]

Okay, I did some diagnostics to see what I could sus out.

No idea if this will prove to be of any value, but here's what I've determined so far:

The wav files play fine up until around 36000 bytes, and after that they start to get truncated. I can't hear truncation on a 35941 byte wav, but can on a 37102 byte one.

They'll then continue to play, albeit truncated up to about the 49000 byte mark where they crash xbmc.

The largest wav that I saw play without crashing was 48326 bytes. It was truncated, but didn't crash. The smallest wav I've seen crash xbmc was 48872 bytes.

So again, no idea if the specific numbers above are of any value, but I can say now with extremely high confidence that it's definitely related to the length of the wav files being played.

If you replace one of the skin GUI sounds with this wav file, does it crash the same way?
Can you upload a crashing wav file and I'll have a look.

[ruuk]

It seems you can't test Cepstral on the Raspberry Pi for free like the other platforms. It's $30, no refunds
Plus you have to actually call them on the phone to get it. I guess linux users get to relive the 90's

---

Okay, I did some diagnostics to see what I could sus out.

No idea if this will prove to be of any value, but here's what I've determined so far:

The wav files play fine up until around 36000 bytes, and after that they start to get truncated. I can't hear truncation on a 35941 byte wav, but can on a 37102 byte one.

They'll then continue to play, albeit truncated up to about the 49000 byte mark where they crash xbmc.

The largest wav that I saw play without crashing was 48326 bytes. It was truncated, but didn't crash. The smallest wav I've seen crash xbmc was 48872 bytes.

So again, no idea if the specific numbers above are of any value, but I can say now with extremely high confidence that it's definitely related to the length of the wav files being played.

If you replace one of the skin GUI sounds with this wav file, does it crash the same way?
Can you upload a crashing wav file and I'll have a look.

If you can run

Code:

espeak -w test.wav "This is a wav that should probably crash"

on a Pi, that will get you the wav.

[ruuk]

I made a little backend that uses a well known but undocumented Google online TTS server. It works surprisingly well and the voice is high quality. It returns mp3's so it only works on a system with mplayer installed (that's currently the only player the addon can use that can play mp3's).

I wonder how many of us would have to use this before google removes public access to it

[eckythump]

Ruuk:

Tested some for you. Large wavs crash skins, too. It appears the wavs are pre-cached for skins so xbmc will crash on startup if there's a too-big wav present.

I installed the Quartz skin and it crashed xbmc when I tried to switch to it due to the size of the Notify.wav file. I made it smaller (I just copied Click.wav over the top of it) and it was happy. When I used your suggested test.wav and copied that over the top of Back.wav, it started crashing again on startup.

I'm currently using the espeak backend for testing. I figure that's the easiest way you and I can be consistent with one another and is less complicated with less points of failure than using ttsd/httpttsd.

But the crashing behaviour with the quartz skin seems like a good thing to me. I'm terribly behind today, but when I get a little more time, hopefully tonight, I'll do a fresh install of OpenELEC 0.95.6 and install the quartz skin and confirm that it crashes before we even do anything with xbmc tts. If it does crash as I expect it will, then that's a bug that'll probably be easy to get looked at and fixed quickly.

[VIJO]

@@

[eckythump]

Ruuk:

Alright. I did a fresh install of OpenELEC 3.95.6. I then installed and switched to the Quartz skin. I haven't installed anything else or made any settings changes whatsoever.

I'm able to install and use the Quartz skin without crashing, but if I replace one of the wavs in /storage/.xbmc/addons/skin.quarts/sounds with a larger one, and then restart xbmc, it will crash if the wav is big enough.

So you can try and reproduce, I used espeak.

Code:

OpenELEC:~/.xbmc/addons/skin.quartz/sounds # cp Back.wav Back.wav.orig
OpenELEC:~ # cd /storage/.xbmc/addons/skin.quartz/sounds/
OpenELEC:~/.xbmc/addons/skin.quartz/sounds # espeak -w Back.wav "1 2 3 4 5 6"
     ... restart xbmc, once started, pres escape and hear 1 2 3 4 5 6
OpenELEC:~/.xbmc/addons/skin.quartz/sounds # espeak -w Back.wav "1 2 3 4 5 6 7"
     ... restart again, now it'll continously crash on startup ...
OpenELEC:~/.xbmc/addons/skin.quartz/sounds # cp Back.wav.orig Back.wav
    .... so it'll stop crashing and start again ...

You may notice that the "1 2 3 4 5 6" wav is being cut short when played, making the "six" sound more like "sick".

Another thing I noticed is that it seems to be more the playing time of the wav than the filesize that pushes it over the limit. If you look at the size of Notify.wav you'll see it's bigger than the 50kish sized wavs I was getting crashes with on earlier testing. My wavs were 8 bit mono @ 22050Hz, this is 16 bit stereo @ 44100Hz, so 8 times the size for the same duration.

Ruuk: Are you able to submit a bug report to OpenELEC about this?

[popcornmix]

Ruuk: Are you able to submit a bug report to OpenELEC about this?

If you are referring to a crash occurring on the Pi then no. It's an xbmc issue not an OpenELEC issue, and I'm the person who needs to know (assuming I can reproduce it from your description, it will be fixed).

[popcornmix]

If you are referring to a crash occurring on the Pi then no. It's an xbmc issue not an OpenELEC issue, and I'm the person who needs to know (assuming I can reproduce it from your description, it will be fixed).

I've got a fix. Basically a calculation of "CalcDstSampleCount)() = (src_samples * dst_rate + src_rate-1) / src_rate" was overflowing.
I've pushed a fix to newclock3 and gotham_rbp_backports trees, which is used by Milhouse builds, and hopefully the official gotham openelec beta.

Note: this fixes the hang. I can see the last word getting truncated, but that occurs with both the Pi sink and the ALSA sink, so I'm guessing that is a limit of skin sounds.
FernetMenta may be able to confirm this.

[ruuk]

Ruuk: Are you able to submit a bug report to OpenELEC about this?

If you are referring to a crash occurring on the Pi then no. It's an xbmc issue not an OpenELEC issue, and I'm the person who needs to know (assuming I can reproduce it from your description, it will be fixed).

Do you know the reason this only causes crashes on the Pi when using OpenElec? I haven't had an issue with RaspBMC previously or just now when I upgraded to the newest nightly. We've also haven't experienced the issue on any other platform.

If you are referring to a crash occurring on the Pi then no. It's an xbmc issue not an OpenELEC issue, and I'm the person who needs to know (assuming I can reproduce it from your description, it will be fixed).

I've got a fix. Basically a calculation of "CalcDstSampleCount)() = (src_samples * dst_rate + src_rate-1) / src_rate" was overflowing.

Just so I understand, was this a fix in the code for the Pi sound specifically or in code that is used on all platforms.

I've pushed a fix to newclock3 and gotham_rbp_backports trees, which is used by Milhouse builds, and hopefully the official gotham openelec beta.

Note: this fixes the hang. I can see the last word getting truncated, but that occurs with both the Pi sink and the ALSA sink, so I'm guessing that is a limit of skin sounds.
FernetMenta may be able to confirm this.

Well, as far as the addon goes, I can probably at least short term fix that by adding silence to the end of the wav.

Unless it cuts sound after a certain duration, it sounds like there must be some other bug that's causing it to drop a certain fraction off the tail of a wav. Maybe eckythump can weigh in on that as he's done the testing with progressively longer wavs.