Working TTS on the player (using flite)

Posted by: TheAmigo

Working TTS on the player (using flite) - 17/11/2002 20:47

So I thought I'd see why everyone talked about flite, but didn't use it. The download page for flite even has a linux ARM binary!

The first thing I noticed was that it wanted a newer version of libc. My empeg has 2.1.2 (I'm running 2.0b11) and flite wants 2.1.3. So I grabbed the libc6 package from debian Potato (also pre-compiled for ARM). I did kinda get myself in trouble here... I wasn't thinking about it when I went to swap in the new libc. I rm'd the link to the old one and tried to put a link pointing to the new one. Well, the ln command doesn't work when neither of them is there (duh). Luckily, I was able to use kftpd to put the new one in place (since it's in the kernel and not trying to load libc every time I type something).

Anyway, with flite and libc 2.1.3, I gave it a try. Well, it can't output audio directly on the empeg, but it can create a .wav file. So I created a simple text file and had flite read the text into a .wav. Then I used pcmplay to play the wav. Since flite created a 8KHz mono sample and pcmplay assumes 44KHz stereo, it just sounds like a high-pitched beep.

Rather than do a proper re-sampling, I wrote a quick hack to just read 2 bytes (16 bit samples) and write those same 2 bytes back 11 times. The result actually sounds decent.

The next challenge was to make it so you don't have to run 3 commands everytime you want it to say something. To do this, I created a fifo and added to my sample duplicator prog to sit in a loop reading from the fifo. I have a wrapper shell script around this that pipes the output to pcmplay too. Then I called the shell script from preinit.

The end result? I can read any text file on the system with a single command.

It still needs a bit of work smothing things out though. Installation is a bit tedious and I don't have a readme, but I'll see if I can put some sort of package together with some basic instructions tonight.

I'm a little nervous that the libc2.1.3 (from debian) is only 900K whereas the 2.1.2 (empeg 2.0b11) is 950K. Maybe my player won't boot next time I shutdown.... I'll make sure to test this before giving out instructions
Posted by: tonyc

Re: Working TTS on the player (using flite) - 18/11/2002 12:34

ROCK!

I had gotten as far as the "three separate commands" solution. (flite -> rateconv -> pcmplay.) I hadn't thought of a fifo -> pcmplay solution. I was thinking that it'd be nice if Flite could be patched to write directly to the empeg's sound device after the sound is up-sampled, but that's probably a bigger step.

It sounds like what you've got might work pretty well. I'm curious, does it work when the player app is running? I know there is/was a kernel hack to do sound overlay, and I thought it might have been incorporated into Hijack. That'd be really sweet. Then GPSapp could read directions, for instance.

Also, how is the memory usage? Can you run Flite without swap while the player is running? I was having problems with it when I tried back in the Flite 1.0 days.
Posted by: TheAmigo

Re: Working TTS on the player (using flite) - 18/11/2002 13:46

I was using flite 1.1 and I'm not sure how to check memory usage.

I tried it while the player was playing and no, it sounds just like DomoKun's date anouncement... so bad that you can't make out the speech. But pausing the player (without quitting), it plays just fine. I haven't tested any large files, just some short phrases. I'd like to see if I can re-compile flite and add a couple features (like upsampling and writing to stdout).

For a GPS app, it looks like it would have to pause the music, speak and unpause. I'm still interested in working towards my initial goal, but I haven't even started on IrDA (which AFAIK isn't in hijack kernels).
Posted by: tonyc

Re: Working TTS on the player (using flite) - 18/11/2002 14:00

Well, actually, I think if it's stuttering, it's probably due to too much CPU usage rather than the sound driver's inability to interleave sounds.

Take a look at this old post. This kernel patch may not have been included in Hijack, but if you patched it in, I think you'd have better results. PCMplay would just have to open the audio device with O_SYNC.

Oh, and to see how much memory flite is using, run the following from a shell prompt when flite is running:

ps -eorss,pcpu,pid,args | fgrep flite

The first column will be the RSS, or resident size, in kilobytes.
Posted by: DomoKun

Re: Working TTS on the player (using flite) - 18/11/2002 14:06

In reply to:

I tried it while the player was playing and no, it sounds just like DomoKun's date anouncement... so bad that you can't make out the speech.



You probably have other 'M' preinit scripts that are being run simultaneously to my TTS Clock program, or you tried R1 of my program. You can rename your other M scripts to B scripts that are alphabetically after B10tts and you will notice that it reads the time flawlessly using an AT&T Natural Voices recording.

Although flite is really cool, I still think prerecorded TTS would produce a better end result then flite can. Compare a recording of flite http://freetts.sourceforge.net/docs/audio/talkforever.wav to a recording of demo of the AT&T voice http://www.naturalvoices.att.com/demos/index.html In car, I think that flite might be very difficult to understand while a voice like AT&T Natural Voices would be much easier to understand. If the price of the AT&T Natural Voices is too much, the free TTS provided by L&H and Microsoft are superior to flite as well http://www.microsoft.com/msagent/downloads.htm#tts
Posted by: TheAmigo

Re: Working TTS on the player (using flite) - 18/11/2002 14:33

Oh, don't get me wrong, even with flite working I'll still use your ttsclock. It's much higher quality. But flite is already ported to the ARM and runs in the tight memory requirements. For something like a clock, pre-recorded speech is a good solution, but I'm looking for ways to do dynamic speech... e.g. reading directions from a GPS or reading messages that come in on my pager.

If I have ttsclock's startup script called B10tts, it doesn't work because the drive isn't mounted. Named with an M, it's interleaved with the music... I looked at the source for preinit to see about adding a W (wait like the B does, but after mounting), but it forks to wait for the mounting to happen so it's beyond my ability to add such a feature.
Posted by: TheAmigo

Re: Working TTS on the player (using flite) - 18/11/2002 14:58

Ok, I read the thread. I don't know if I have the patch or not. I'm running Hijack v300 kernel and don't know how pcmplay works... guess that's a no then, eh?

So, the next question is: is there enough CPU power to run flite, decode mp3s and mix the two all at the same time. If not, we may be stuck with running flite to generate temp files and then mix them. That would add a short delay, but shouldn't be too bad.

I'm guessing that both GPS and OBD-II projects can probably pre-precord PCM files with better TTS systems for what they need. I know why I want want TTS, what other uses to people have in mind?

802.11b to your house so when you get close to home, your computer can tell you how many new email messages you have, what new shows your TiVo has recorded and how many files have finished downloading off edonkey?


Posted by: tonyc

Re: Working TTS on the player (using flite) - 18/11/2002 15:17

So, the next question is: is there enough CPU power to run flite, decode mp3s and mix the two all at the same time. If not, we may be stuck with running flite to generate temp files and then mix them. That would add a short delay, but shouldn't be too bad.


That's exactly the approach I'd take. Let flite do its work in the background at a relatively low priority, and when it's complete, play the result.

I have little or no use for the "prerecorded TTS" strategy. The main thing I want TTS for is so my emptriv game can read questions and answers, and provide voice responses to correct/incorrect answers. So on long trips, I can play it without looking at my screen. It would be impractical to generate WAV files for thousands of trivia questions, so real-time TTS is ideal.

I also thought it would be neat if GPSapp used flite to speak directions to the user, and I still think that strategy is better than having to transfer a bunch of WAV files over to your Empeg when you save a route. But since I'm not a contributor to GPSapp, nor do I have a GPS receiver right now, that's not as big on my agenda.
Posted by: TheAmigo

Re: Working TTS on the player (using flite) - 19/11/2002 00:57

I've gotten a lot of cleanup work done, but I'm not quite ready to release anything yet. I still need to write an install script and some basic documentation.

I've now worked out a couple basic details:
- recompiled flite so it works with the stock libc (upgrading is tricky so it's nice not to have to)
- modified flite so it can write PCM to stdout if asked to.
- modified my pcmcvt to read stdin
- rewrote shell wrapper so now it can read plain text from a fifo.

So the way it works now is that you can write any text to /usr/local/ttsd and it will say it. For example:

sh-2.03# echo hello world > /usr/local/ttsd

This should make it fairly easy to interface with.

Future work to be done:
- pause the player before doing TTS and unpause when done.
- try to integrate upsampling into flite (saves a little ram)
- look into mixing with music
- what to do about generating a wav before reading it... where to store the temp file?

I should be able to realease a beta version tomorrow (well, later today, it's 2am and I'm going to bed) for people to play with.
Posted by: tonyc

Re: Working TTS on the player (using flite) - 19/11/2002 12:25

Sounds cool so far. Looking forward to it.

If you think it'd be helpful, I can try to apply the audio overlay patch to a Hijack v300 kernel. I gave it a quick shot last night but the patch was rejected, so it's going to take some time to manually figure out why it didn't take and hammer it in there... But it should be doable.

I can also hack up a version of pcmplay that will take advantage of the audio overlay. That's a much quicker fix.

Hopefully when Mark Lord comes back we can get him to include the audio overlay support as part of Hijack.
Posted by: TheAmigo

Re: Working TTS on the player (using flite) - 19/11/2002 14:24

A patched kernel and/or pcmplay would be very helpful!

I seem to recall a discussion from long ago that to play PCM audio on the empeg had some special requirements (like writing a certain block size at a time or something). Is that what pcmplay does? It's the vague memory of such a topic that made me not try to get flite to play audio directly.
Posted by: wfaulk

Re: Working TTS on the player (using flite) - 19/11/2002 15:23

Yup. 4608 Byte blocks. Funny number, huh?
Posted by: TheAmigo

Re: Working TTS on the player (using flite) - 20/11/2002 00:29

Ok, I've finally packaged together a working system. It's 2.5M compressed (4M uncompressed) and nearly all of the size is flite. It's still an alpha release because I haven't had anyone else test it yet. If you're interested, please download it and let me know what kind of problems you find.

Due to the size, you may not be able to extract it on the default / partition (2.5M .tgz + 4M of extracted files is a good percentage of the default size). Suggested installation:

rwm
mkdir /drive0/src
(upload ttsd-1.0a1.tgz to that dir)
cd /drive0/src
tar zxvf ttsd-1.0a1.tgz
cd ttsd-1.0a1
./install

Posted by: oliver

Re: Working TTS on the player (using flite) - 20/11/2002 01:29

Not too bad, reminds me of the talking moose

Install was almost very simple, had to delete some junk i had in my root directory.

Also, i've attached a sound clip demo of tts working on my empeg.

Edit: Does anyone have a version of top or something similar that works on the empeg?
Posted by: ilDuce

Re: Working TTS on the player (using flite) - 20/11/2002 05:26

I had some troubles too.... First I had to create the /usr/local/ and local/bin drectory.... I didnt have them for some reason... and the install script didnt create the folders when needed..
Also my empeg freezes when i try to write something to ttsd... Dont know if everything in the installation went as it should.... I just fixed the two folders...
How much time does ttsd need to speak out the frase "Hello world".... without the player executed...

edit: Now I know what the problem was. As i said earlier I didnt have the correct directorys. My solution was to just create them (/usr/local & /usr/local/bin) But that wasnt enough... I didnt get i to work. The reason for this was that I had deleted the preinit script so that the empeg could boot correctly. And then tried to use the same installation folder as before. But the startupscript wasnt left in the installation folder. So that never got installed again... I had to untar everything again.... and then the installation went perfectly.... and now works!!
Posted by: djc

Re: Working TTS on the player (using flite) - 20/11/2002 08:09

Not too bad, reminds me of the talking moose

omg! that's too funny. i had totally forgotten about the talking moose. he was, by far, the coolest thing you could put on your mac back in 1986.

--dan.
Posted by: TheAmigo

Re: Working TTS on the player (using flite) - 20/11/2002 09:07

First I had to create the /usr/local/ and local/bin drectory....
D'oh. The install script checks to see if /usr/local/bin exists and if not, it creates it... but I forgot that /usr/local may not exist which causes it to fail to create /usr/local/bin.

Also my empeg freezes when i try to write something to ttsd..
Maybe a future version will be better, for now, you have to manually pause it before having it speak. I should have said something about that.

And then tried to use the same installation folder as before. But the startupscript wasnt left in the installation folder. So that never got installed again..
Right now, the installer isn't very smart about recovering from errors... if something goes wrong during install, it doesn't know how to pick up from there and continue installing. That's on the todo list.
Posted by: oliver

Re: Working TTS on the player (using flite) - 20/11/2002 12:41

In reply to:

by far, the coolest thing you could put on your mac back in 1986.



Oh Yea, my dad had it on our mac plus! he also used the voice for our answering machine. I would play with that talking moose for hours, clicking on him to hear what he would say

Posted by: leftyfb

Re: Working TTS on the player (using flite) - 20/11/2002 13:17

I'd LOVE for my TTS to emulate the voice of K.I.T.T (William Daniels)

Now to just find an 82 Trans Am to put it in

And ironically, my name IS Michael ;-)
Posted by: tonyc

Re: Working TTS on the player (using flite) - 20/11/2002 13:19

Edit: Does anyone have a version of top or something similar that works on the empeg?

Not sure what utils you have installed on yours, but in the absence of top, a combination of ps, sort, and head can serve as a "poor man's top" in the following combination:


ps -eopcpu,pid,args,rss | sort -rn | head -5

.
This will give you the top 5 programs in order of CPU usage. If you want to sort by memory size instead (flite is probably a bit of a memory hog!) do it this way:


ps -eorss,pid,args,pcpu | sort -rn | head -5

.
Or, just untar top out of Frank's ARM debian image.
Posted by: oliver

Re: Working TTS on the player (using flite) - 20/11/2002 13:29

Thanks Tony,
I'm downloading franks image right now, quick question. Do i have to copy anything else besides top to get only top to work on my empeg?
Posted by: tonyc

Re: Working TTS on the player (using flite) - 20/11/2002 14:05

Not sure. libproc.(something).so probably needs to be in your /lib directory... Give it a shot and see if it complains.
Posted by: mtempsch

Re: Working TTS on the player (using flite) - 20/11/2002 14:12

top on my home Linux box wants libncurses too...

~$ ldd `which top`
libproc.so.2.0.6 => /lib/libproc.so.2.0.6 (0x4001a000)
libncurses.so.5 => /lib/libncurses.so.5 (0x40026000)
libc.so.6 => /lib/libc.so.6 (0x40065000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

/Michael
Posted by: oliver

Re: Working TTS on the player (using flite) - 20/11/2002 14:13

Error loading shared libraries: libproc.so.2.0.0
After i copy that file to /lib
i get this
Error loading shared libraries: libncurses.so.4 cannot open shared object file
After i copy that file to /lib i get this error
Error loading shared libraries: libncurses.so.4: cannot read file data: no such file or directory.

I remember there being some kinda library link command?
Posted by: peter

Re: Working TTS on the player (using flite) - 20/11/2002 14:16

Error loading shared libraries: libncurses.so.4 cannot open shared object file
After i copy that file to /lib i get this error
Error loading shared libraries: libncurses.so.4: cannot read file data: no such file or directory.

I remember there being some kinda library link command?


/sbin/ldconfig

Are you sure that the libncurses.so.4 you copied wasn't a symlink -- to a file the empeg doesn't have? What you're doing should in theory work.

Peter
Posted by: tonyc

Re: Working TTS on the player (using flite) - 20/11/2002 14:18

Ummm I can't telnet into my Empeg here at work, but I'll look at the dependencies and such tonight... Unless someone beats me to it.

My initial guess is that you've got a symbolic link in /lib pointing to nothing, or you need to add a symbolic link somewhere, one of the two.

Edit: Must be a slow day in Cambridge if Peter is here doing tech support!
Posted by: oliver

Re: Working TTS on the player (using flite) - 20/11/2002 14:21

is /sbin/ldconfig a program? because its not on my empeg

I'm not sure what libncurses.so.4 is. Whatever it is, is 0k in size
Posted by: tonyc

Re: Working TTS on the player (using flite) - 20/11/2002 14:23

Yup, that's a symlink. Just untar the whole /lib directory to some temp directory and copy in everything in that directory starting with /lib/libnc* or something to that effect. That should get the links and the real files.
Posted by: mtempsch

Re: Working TTS on the player (using flite) - 20/11/2002 14:23

Do 'ls -l libncurses.so.4' and you'll see if it's a regular file or link

/Michael
Posted by: TheAmigo

Re: Working TTS on the player (using flite) - 21/11/2002 00:23

I've made a couple updates and now you can download 1.0a2.

Changes since last release:
- now uses flite's 16KHz voice (as opposed to 8KHz)
- has pcmcvt integrated into flite (one less process taking up memory)
- slightly improved rate conversion (still much simpler than a proper rate converter, but it's less CPU intensive... the sound quality difference is akin to scanning one of Mondrian's paintings at a slightly lower resolution)
- directory creation bug fix in the installer

The 16KHz voice increases the size of flite from 4M to 5.9M. Obviously, the size of the .tgz increases as well. This means that it almost certainly won't fit all on your root partition (unless you've enlarged yours). If this is a problem for you, you'll know it when you try to extract the archive, before even trying to run the installer.

If there are any volunteers out there, the installer could use some help... needs to check for errors and recover more gracefully.

I'm also not sure where pcmplay came from. Who wrote it? Where's the source? Am I allowed to hack it apart and reuse the code?
Posted by: FlibblE

Re: Working TTS on the player (using flite) - 21/11/2002 03:14

In reply to:

Now to just find an 82 Trans Am




heheh, I've got the Trans Am with empeg install, but my names not Michael! damn, there's always one thing missing!
Posted by: DomoKun

Re: Working TTS on the player (using flite) - 21/11/2002 06:45

you can find the pcmplay source at http://www.empeg.mars.org/devel/hardware/audio.php3
Posted by: tonyc

Re: Working TTS on the player (using flite) - 21/11/2002 09:19

PCMplay is totally free code. I think Rob Leslie contributed it, and didn't put any kind of licensing on it or anything. Making Flite write to the Empeg's audio device natively would be *sweet*.
Posted by: tonyc

Re: Working TTS on the player (using flite) - 21/11/2002 11:02

Okay here is my attempt to put the audio overlay patch into a Hijack v300 kernel. I also built it with IrDA. I haven't tested this kernel out (I'm at work now and can't put it on my Empeg), but I built it from a regular Hijack v300 kernel tree. The audio overlay patch didn't go in very easily, but I think I did it right.. Give it a shot.

I also threw together a pcmplay binary which should theoretically take advantage of this (opens /dev/audio with O_SYNC.) Source here. Also untested.
Posted by: TheAmigo

Re: Working TTS on the player (using flite) - 21/11/2002 12:30

Sweet!

I'll give it a try when I get home tonight. In testing, if you wanna have flite write to a temp file rather than stdout, you can specify an output filename as a second arg. A filename of "stdout" is a keyword that triggers my modifications, any other filename will run the regular unmodified code.

My goal is to get rid of the ttsd shell script and have everything it does integrated into flite. In 1.0a2, pcmcvt is now integrated so that's one down. Next up will be pcmplay. After that, I'll see about having flite sit in an endless loop reading from the fifo. I haven't tried yet, but I suspect it may be harder (having to worry about resetting globals and such that are expecting the program to end).

With IrDA support on the empeg end, I guess I'd better get started writting code for my pager too so I can test it out. By default, it beams stuff in a Palm-compatible format (memos, contacts, todos, etc) ... maybe there are already tools available for Linux to interpret those kinda things.
Posted by: wfaulk

Re: Working TTS on the player (using flite) - 21/11/2002 13:26

    A filename of "stdout" is a keyword that triggers my modifications
Assuming that your modifications are that it writes to stdout, a (much) more standard way of telling that to an app is to use the argument `-' (a single hyphen).
Posted by: genixia

Re: Working TTS on the player (using flite) - 21/11/2002 13:46

Please don't completely lock up the irda port so that other applications can't write to it...

I have a vision of GPSapp being able to talk directions, and also beam GPS NMEA messages to a laptop, so please don't make that mutually exclusive
Posted by: TheAmigo

Re: Working TTS on the player (using flite) - 21/11/2002 13:51

Yeah, I prolly shoulda used a hyphen. Their code already had special cases for "play" and "none" so I wasn't really thinking about it. Seems odd that they chose those rather than traditional --options. I'll prolly change that this weekend.
Posted by: TheAmigo

Re: Working TTS on the player (using flite) - 21/11/2002 14:01

Please don't completely lock up the irda port so that other applications can't write to it...

Are you currently using a kernel with IrDA support? With Tony's patched kernel that includes IrDA, I'd plan to have an application listening to it constantly, but that's a seperate application and just on my own empeg, not anything I plan to include in ttsd. Was that your concern?
Posted by: ilDuce

Re: Working TTS on the player (using flite) - 21/11/2002 15:53

well... Tony.... when are you going to incorporate ttsd into emptriv?..... I am REALLY waiting for that!!! I guess youre waiting for pcmplay to get integrated into ttsd..... and then, the day of the emptriv begins right?.... Hoping for a release soon!!!
Posted by: tonyc

Re: Working TTS on the player (using flite) - 21/11/2002 16:15

and then, the day of the emptriv begins right?.... Hoping for a release soon!!!

Well, the sequence for Emptriv goes more like this:

0) Finish up school for the semester.
1) Port emptriv's graphics routines to Richard Kirby's vfdlib. I'm currently using the dog-slow GD graphics library which is certainly not Empeg-optimized.
2) *then* start playing with having it use ttsd. I can't wait... I *never* play Emptriv now because I'm always driving in my car (passengers love it though.) It would be *real* sweet to play it with TTS capabilities, and since I've got a steering wheel remote, I could legitimately do it without endangering fellow drivers.

I might try to sneak porting Empwake and Empan to vfdlib somewhere in between, in fact, since Empan is the simplest code, I might start with that, just as a guinnea pig for vfdlib.

This ttsd is sounding really sweet, though. I'm wondering what kind of memory it's taking up though... I think I'll try to play with it tonight.
Posted by: genixia

Re: Working TTS on the player (using flite) - 21/11/2002 16:39


I'd plan to have an application listening to it constantly, but that's a seperate application and just on my own empeg, not anything I plan to include in ttsd. Was that your concern?


Yes, that was my concern...You understand.
Posted by: TheAmigo

Re: Working TTS on the player (using flite) - 21/11/2002 20:43

Wow, that works great!

I installed that kernel and replaced the old pcmplay with your patched version. CPU time isn't a problem! I'm quite impressed! While playing mp3s, I can have it read text (using ttsd 1.0a2 which is 16KHz flite). There's about 3 seconds delay after I hit enter before it says "hi" and that seems just fine to me.

Seems like a well-planned feature that the audio is mixed in such a way that the music softens when the speech is playing and then restores back to normal. I'd guess that's just what happens when you add two waveforms together and divide by two, but it sounds like a well-written feature

Two problems though One is: after intalling the patched kernel, my display is all snowy (the left side is animated snow in time with the music). Doesn't seem to effect anything else though (buttons work fine, telnet and ftp work fine).
The other is that after speaking, the music returns to the volume it was at, but a second later, ups to max volume. Ticking the volume knob up or down at all restores it to where it should be, is it possibly just a side-effect of the same bug that's messing up the display?

With the patched kernel and pcmplay, ttsclock gains the same benefit. It can tell the time without causing the music to skip.
Posted by: tonyc

Re: Working TTS on the player (using flite) - 21/11/2002 22:16

Okay, after figuring out that the "pcmplay" in 1.0a2 doesn't open in O_SYNC, I finally got ttsd working as I expected it to. I'm *shocked* that I got the audio overlay patch to work right the first time! I was *sure* something in Hijack would confuse it somehow.

Anyway, no snow here, not sure why you're getting that. Any more information? When does it happen?

I also get the volume spike after it fades down and up. The BG music volume is configurable (well, via #defines) in the audio overlay patch:

/* Audio overlay specific variables */
#define AUDIO_OVERLAY_BUFFERS (16)
#define MAX_FREE_OVERLAY_BUFFERS (AUDIO_OVERLAY_BUFFERS - 2)
#define AUDIO_OVERLAY_BG_VOLUME_FADED (0x00004000)
#define AUDIO_OVERLAY_BG_VOLUME_MAX (0x00010000)
#define AUDIO_OVERLAY_BG_VOLUME_FADESTEP (0x00000AAA)

int audio_overlay_bg_volume = AUDIO_OVERLAY_BG_VOLUME_MAX;

.
But I suspect that the spike has something to do with Hijack and/or Voladj logic. Maybe we can ask Mark Lord... But I'll see if I can find something... But I'm really impressed that all this is working this well already... Great stuff!
Posted by: tonyc

Re: Working TTS on the player (using flite) - 21/11/2002 23:30

Allright, I'm stumped. If anyone else wants to try to figure this out, I'm attaching a modified version of Kim Salo's audio overlay patch which should apply cleanly against a Hijack v300 kernel tree. Hopefully someone can find the source of the volume spike.

I sent the patch to Mark so maybe he can hopefully (a) integrate it into hijack and (b) spot the reason the volume is spiking after the pcmplay output is done. Not sure if he's back to Empeg hacking just yet, though, so maybe we'll have to fight this one ourselves.

Posted by: TheAmigo

Re: Working TTS on the player (using flite) - 21/11/2002 23:37

What's with the calls to concat() in pcmplay.c? I don't seem to have anything the defines a concat() function. I had to change them to open so it would compile... am I missing something?

Why is it that if I put parens after open in the paragraph above, it changes the word open to concat?!
Posted by: tonyc

Re: Working TTS on the player (using flite) - 21/11/2002 23:57

huh?
Posted by: TheAmigo

Re: Working TTS on the player (using flite) - 22/11/2002 00:54

Ok, the new version of ttsd, 1.0a3 is available for download.

It includes the audio overlay patch. Tony, with an unpatched kernel, does it work the same as before or does it not run?

The other big change (for me atleast) is that pcmplay is now integrated into flite. So this version is slightly smaller. I don't yet have looping logic in flite, so it still needs the shell script to run it again after it says something. When I get that included, then the memory footprint won't include bash (yay).

I was expecting to have to play with priorities and worried about giving flite a low priority and pcmplay a higher one (making integration difficult), but that wasn't even an issue... just running at default priority works fine.

In this version, I broke the ability to have flite write to a file (it will only write to /dev/audio). I'll put that back in the next version... it was just easier to force it for now.
Posted by: Crapaddict

Re: Working TTS on the player (using flite) - 22/11/2002 02:36

In reply to:

In reply to:
--------------------------------------------------------------------------------

Now to just find an 82 Trans Am



--------------------------------------------------------------------------------



heheh, I've got the Trans Am with empeg install, but my names not Michael! damn, there's always one thing missing!



http://qdbp.spondooliks.org/img/best_picture_ever.jpg
*grin*
Posted by: wfaulk

Re: Working TTS on the player (using flite) - 22/11/2002 07:45

Dude, that really is the best picture ever.
Posted by: tonyc

Re: Working TTS on the player (using flite) - 22/11/2002 07:57

. Tony, with an unpatched kernel, does it work the same as before or does it not run?

Um, I dunno, why dontcha try it?

It seems to me that the unpatched kernel won't know what to make of the O_SYNC flag when the audio device is opened... It might just ignore it but I haven't tried it out.

Glad to hear you merged the audio routines in. This is really looking great. I threw about a hundred random trivia questions at ttsd last night just for fun and I'd say 80% of them were perfectly understandable, another 15% had a word or two that got jumbled, and another 5% I kinda had to read the question to understand. That's not too bad. I could theoretically put in a phonetic version of the question for tough-to-pronounce words, but I'm not sure I'll care enough to do that.

Maybe we should start asking Alan Black about the timetable for a 1.2 release of Flite... Or maybe look into a group buy of his commercial product...
Posted by: leftyfb

Re: Working TTS on the player (using flite) - 22/11/2002 08:53

Is it just me or do these "icons from childhood" look a hell of a lot LESS cooler as they did when we were little?
Posted by: genixia

Re: Working TTS on the player (using flite) - 22/11/2002 09:03

<KITT>What you talkin' 'bout Michael?</KITT>
Posted by: genixia

Re: Working TTS on the player (using flite) - 22/11/2002 10:00

Since that patch was originally written, I've hacked the way that the main volume control works for the volboost_ functionality. There's a couple of things that you can do to see if this is a factor.

1) Ensure that any volboost_ parameters in config.ini are set to zero. (or commented out).
2) Try adjusting the volume manually after the TTS output has finished. If it 'jumps' to the correct level, then there is a fair chance that there is a conflict.
3) You could also try recompiling with HIJACK_VOLBOOST_DEBUG set and then watch the serial port, which will output the following whenever the player changes the volume:
"VOLBOOST: Req: %d, Boosted: %d, Appl. Boost: %d, Appl. Vol: %d\n"

Req is the volume that the player is trying to set.
Boosted is the volume calculated once any boost parameters have been set. ( should be = Requested with volboost_ parameters all 0)
Applied boost reflects the amount of boost/cut actually applied. As long as the calculated volume level stays within 0 - 100, then this will be equal to the volboost_parameter. (which we set to zero)
Appl. Vol is the actual volume level sent to the mixer. (What we are really interested in here.. Should be same as Req.)

This might not tell us much, except give us some sanity. Ideally the overlay patch should be ported to to use the volboost code anyway - take a look in the MIXER_WRITE(SOUND_MIXER_VOLUME) and MIXER_READ(SOUND_MIXER_VOLUME) ioctls in empeg_mixer.c to see how that should be done....basically we wrap any userspace volume write/read with a couple of functions that fiddle the numbers according to the current volboost.
Posted by: tonyc

Re: Working TTS on the player (using flite) - 22/11/2002 11:14

Okay, definitely worth investigating... Maybe I'll look at it this weekend, though since I wrote neither the overlay patch nor the volboost patch, I'm coming in a little cold... But it'll be an interesting challenge, I suppose.
Posted by: tonyc

Re: Working TTS on the player (using flite) - 22/11/2002 23:52

Allrighty, here's what's happening when HIJACK_VOLBOOST_DEBUG is set...

1. I turn the volume down to something low:

Boosted: 28, Requested: 28, Current Boost: 0
VOLBOOST: Req: 27, Boosted: 27, Appl. Boost: 0, Appl. Vol: 27
Boosted: 27, Requested: 27, Current Boost: 0
VOLBOOST: Req: 26, Boosted: 26, Appl. Boost: 0, Appl. Vol: 26
Boosted: 26, Requested: 26, Current Boost: 0

.
2. I send some text to the ttsd:


sh-2.03# echo "Can you hear me now?" > /usr/local/ttsd

.
3. After a couple seconds of processing, ttsd writes its output, the audio overlay patch does it's thing, fading down the background music, playing the buffers, and fading the music back up to the *correct* previously stored volume (26 in this example.) No debug output is shown from the volume boost debug statements at this point.

4. About a second later, after the "fade up to the previous volume" code from the overlay patch does its work, the volume spikes up, and we see this debug output:

VOLBOOST: Req: 85, Boosted: 85, Appl. Boost: 0, Appl. Vol: 85
Boosted: 85, Requested: 85, Current Boost: 0

.
5. At this point, as you had suggested might be the case, if I turn the knob a single click, the volume "jumps" to the correct volume:

VOLBOOST: Req: 25, Boosted: 25, Appl. Boost: 0, Appl. Vol: 25
Boosted: 25, Requested: 25, Current Boost: 0

.

So... Any ideas? I could dig deep into the code and start putting printk's everywhere, but since you wrote the volume boost, maybe you have an idea where this "phantom" volume change is coming from after the overlay patch is done its work?
Posted by: genixia

Re: Working TTS on the player (using flite) - 23/11/2002 07:01

Ok, the jump occurs because the overlay code has changed the volume and the player isn't aware of this change. The player keeps tabs on what it *thinks* the volume is and doesn't read what it *really* is before changing it. (We could consider this a player bug, but there may be reasons for this...) So any volume change in the kernel must be kept hidden totally from the player, hence the reason that the volboost code is written the way it is.

What is interesting is that the overlay code appears to use a non-volboost compatible method of lowering the volume, which is why we don't see the debug messages when that happens.
But when it raises the volume, it appears to use a method that is volboost compatible - hence the messages. This disparity needs to be addressed to avoid sending volboost nuts.

The test has also told us that volboost itself isn't causing the issue - something is explicitly asking for a volume level of 85, and volboost isn't adding anything of it's own. BTW, that means row 85 in the volume table, which should be about -2.5dB IIRC. (row 90 is 0dB)

[edit]
Ok, I've just re-read your post more carefully, and you allude that the patch does raise the volume correctly to start with, and the jump is an additional volume change.... let me go read the patch.
Posted by: tonyc

Re: Working TTS on the player (using flite) - 23/11/2002 11:04

and you allude that the patch does raise the volume correctly to start with, and the jump is an additional volume change.... let me go read the patch.

Yup. About a second after the "non-volboost-compatible" raising of the volume to the correct "previous" volume, there's a "volboost-compatible" one that comes through from *somewhere* which raises it to 85. Really strange. I couldn't find anything that was explicitly setting it like that, maybe your luck will be better.
Posted by: genixia

Re: Working TTS on the player (using flite) - 23/11/2002 15:47

Ok, just installed a patched v300, and flite...

My first observation is that both volume changes are incorrect - they appear to be to fixed volume values, and not dependant on previous volume setting.

But it also appears that volume control is being done twice - possibly once by sample scaling?? Try turning the volume right down with music playing and then try ttsd - you'll get 2 spikes, one of either side of the tts output. I'm going to take a look at pcmplay.c, as I have a suspicion that this may be happening outside of the kernel - and that with the overlay patch that volume changes may not even be needed.


Posted by: tonyc

Re: Working TTS on the player (using flite) - 23/11/2002 17:09

Cool, look forward to seeing if we can fix this one. I emailed Mark and he didn't seem adverse to the idea of including the patch in Hijack, provided the volume spike gets fixed. I think it's a great feature.
Posted by: genixia

Re: Working TTS on the player (using flite) - 23/11/2002 19:07

Ok, since pcmplay has been integrated into ttsd, testing was a little more convoluted....but;

I installed ttsclock to get some nice pcm samples. I then installed pcmplay.overlay, compiled from your source.

Testing with cat /drive0/var/tts/evening.pcm | /programs0/pcmplay.overlay gave the same results - volume spikes.

I then commented out the call to audio_init() in pcmplay.overlay.c, recompiled and reinstalled. No spikes - this is smooth, and the way to go.

One problem with this is that it only works when pcm is already being output. ie, if the player is paused, or in AM/FM/Aux mode, then nothing will be output. (I'm guessing that Soft Audio Mute is set in paused mode) This is an issue, but the original pcmplay code didn't do the right thing anyway - What really needs to be done is;

Get the current source and store it.
Get current SAM status and store it.
Set SAM and change to PCM (if neccessary.)
Unset SAM and pcmplay the sample.
Set SAM and change back to stored source. (if it was changed)
Restore SAM to original state.

This should allow pcmplay to always output files, regardless of current source and mute settings (and restore them afterwards). One could further question whether we'd want to look for a *minimum* volume level that should be active for samples...eg if we've turned the volume right down to have a conversation, and we want GPSapp to announce a turn, should we turn the volume up a bit?
This should be done in a similar way - check and store the current volume, and if it's below a certain level (preferably configurable...but we're only feasibility testing at the moment...can be done later), raise the volume to that level, and flag that we changed it. Do everything else, and then if the flag was set, restore the previous value.

As long as any volume changes are done via the existing ioctl's in empeg_mixer.c, volboost shouldn't conflict in any way. The only way that volboost can really get screwed up is if something within the kernel tries to set the volume directly without taking volboost into account. I don't see any need for this to be the case for pcmplay.

@TheAmigo; Can you comment out the audio_init() call in ttsd?
Posted by: genixia

Re: Working TTS on the player (using flite) - 23/11/2002 19:52

Just to make that story a little more interesting, there is currently no read ioctl for SAM, only a write. Which means that the player keeps tabs on that state too. I'm guessing that since we're going to fix up pcmplay and derivatives to use an overlay patch that needs to be incorporated into hijack, we should consider adding a read ioctl in the same patch, and doing this right
Posted by: tonyc

Re: Working TTS on the player (using flite) - 23/11/2002 20:26

Having read your last message, I already started on the road to a read SAM ioctl. Question though.. Does it make sense for the user app to do the saving/reading of SAM and source, or would it be better to let the overlay code in the kernel do it?
Posted by: tonyc

Re: Working TTS on the player (using flite) - 23/11/2002 21:14

Okay, I modified pcmplay to do what you proposed, and I think I found a problem with your approach... The user app writes data to the overlay buffer and finishes, having no idea when that buffer will finish playing... So how does he know when to un-set SAM?

Seems to me that any switching of source/SAM status would have to be done by the audio overlay code... pcmplay has no concept of when the sample is finished playing. Unless I'm missing something...
Posted by: genixia

Re: Working TTS on the player (using flite) - 23/11/2002 21:58

That's a fine question.... putting it in the kernel overlay code makes config.ini options easy. eg, overlay_vol_min= { 0 <= int <= 100}, overlay_can_unmute={ 0 | 1}, etc., and at the moment I can only see benefits to doing that - we'd be removing the need for an app developer to 'get it right'.

[edit]
I should have hit refresh before posting
Not sure about when pcmplay returns, but that certainly would be another good reason
Posted by: TheAmigo

Re: Working TTS on the player (using flite) - 23/11/2002 22:39

@TheAmigo; Can you comment out the audio_init() call in ttsd?

Sure. I've got family in town for Thanksgiving so I'm not sure how much time I'll be able to spend working on this. I've made the change so it will be in the next release. I've got a few other things I want to finish up before the next release, so I'm not sure when it will be.

Not sure I followed the rest of the thread, but when you guys come up with a final design, I'll be ready to make whatever changes are needed then.
Posted by: tonyc

Re: Working TTS on the player (using flite) - 24/11/2002 01:56

OK, can anyone think of a legitimate reason why the Empeg player app needs to set Soft Audio Mute when the player pauses? I don't get it. The player app itself stops playing... Why bother muting the audio device?

To work around this, I have the EMPEG_MIXER_SET_SAM ioctl dummied up so it's basically a no-op. This allows PCM sounds to play (using the audio overlay patch) while the player is paused. This obviously isn't ideal if we ever want to use SAM for truly muting the player AND the PCM sounds.

If we ever want that, maybe we should ask the Empeg guys why they're setting SAM on pause in the first place, and request that they change it so that it just stops the player without sending the SAM ioctl...

In the meantime, here's the audio overlay patch (prebuilt kernel here) with the SETSAM ioctl dummied up, and with configurable min and max background volume when the PCM is playing, as well as configurable fadestep. The relevant config.ini options are:

overlay_bg_min (min 0, max 0x00010000, default 0x00004000)
overlay_bg_max (min 0, max 0x00010000, default 0x00010000)
overlay_bg_fadestep (min 0, max 0x00010000, default 0x00000AAA)

Unfortunately I have no idea how to convert the hex values to the normal 0-100 volumes we're used to. I tried to correlate them to things in the volume table, but they didn't seem to match any of those columns.

@TheAmigo: There's no real "design"... All you gotta do is comment out the audio_init. Without the audio_init, we shouldn't get the volume spike anymore. BTW, you planning on releasing ttsd source in addition to the diffs against flite?

Posted by: TheAmigo

Re: Working TTS on the player (using flite) - 24/11/2002 09:43

@TheAmigo: There's no real "design"... All you gotta do is comment out the audio_init. Without the audio_init, we shouldn't get the volume spike anymore.

Well, that makes it easy on my end

BTW, you planning on releasing ttsd source in addition to the diffs against flite?

As of 1.0a3, ttsd is a shell script that runs flite and sleep. So the only 2 things in the src dir (included in the archive) are sleep.c (extremely trivial) and cst_wave_io.c which is the only file I've modified in flite's source. The sample rate conversion and 4608 byte buffering are both done at the same time in the pcmplay() function so it doesn't have to copy all the samples around in memory more than once.

In the next version, I'll have to modify more than just one .c file in flite. My goal is to cut down on the number of processes so I'm trying to put all the ttsd code directly into flite. I haven't tested any real memory usage, but I'm guessing that putting the extra code in flite (rather than seperate binaries and/or shell scripts) will allow more of it be swapped out when not in use (leaving more real ram for other apps).

I don't get it. The player app itself stops playing... Why bother muting the audio device?

Having disabled EMPEG_MIXER_SET_SAM, if you're listening to mp3s and press pause, is there any delay before it actually pauses? Maybe the ioctl mutes it so you don't hear it playing what's left in the buffer after you press pause. Even if there is a delay, I'm in favor of your change.

Posted by: tonyc

Re: Working TTS on the player (using flite) - 24/11/2002 10:04

Having disabled EMPEG_MIXER_SET_SAM, if you're listening to mp3s and press pause, is there any delay before it actually pauses? Maybe the ioctl mutes it so you don't hear it playing what's left in the buffer after you press pause. Even if there is a delay, I'm in favor of your change.

Good thinking, but the pause is actually immediate even when I fudge the SETSAM ioctl. At least for me. So I don't think that's why they did it...
Posted by: genixia

Re: Working TTS on the player (using flite) - 24/11/2002 11:13

Soft audio mute is designed to mute/unmute slowly, hence protecting your amp and speakers from ugly sounding and potentially damaging transients. It's not a good idea to disable the ioctl. We don't know for sure what uses it within the player (you could set MIXER_DEBUG which would show you all the calls), but it's fairly safe to assume that it is used when the eq bank is changed, and transients here could be very large. (Ironically it should also be set when changing single eq parameters, but I don't think it is). It's also used when changing source, and as far as I can see, it is the only method used to mute Aux In and the Tuner (since they are analogue inputs). So I can't see disabling the ioctl being a valid thing to do.

The SAM set ioctl is actually a toggle;


case EMPEG_MIXER_SET_SAM:
{
int sam;

copy_from_user_ret((void *) &sam, (const void *) arg,
sizeof(int), -EFAULT);

if(sam) dsp_write(Y_switch, 0);
else dsp_write(Y_switch, 0x5d4); // 4.6ms



Now if we made sam persistant, then it would always hold what the player thought the setting was which is all we really care about. We can force a mute/unmute at will within the overlay code, with the appropriate dsp_write command, and restore it to what the player wants afterwards (I need to find my DSP programming manual to confirm whether 'sam' is inverted or not...I think that sam=0 is muted - this could be tested with MIXER_DEBUG)

With regards to the volume. I haven't tested your code, but I'm guessing that it's not working quite as you were hoping. The overlay volumes that you're touching are AFAIK doing sample scaling - in normal use, the players samples aren't scaled (well, ignoring voladj), so if the main volume is turned down, then you're still not going to hear anything...what you appear to be doing is affecting the player-ttsd balance. (Incidentally, this may have some use in itself - I think that the tts samples ( from ttsclock) are a bit low in volume)

But we need to ensure that we are not scaling the player samples when there isn't any tts active - we don't want to lose any fidelity in the music
Posted by: tonyc

Re: Working TTS on the player (using flite) - 24/11/2002 11:35

The SAM set ioctl is actually a toggle;


case EMPEG_MIXER_SET_SAM:
{
int sam;

copy_from_user_ret((void *) &sam, (const void *) arg,
sizeof(int), -EFAULT);

if(sam) dsp_write(Y_switch, 0);
else dsp_write(Y_switch, 0x5d4); // 4.6ms


IANA Kernel Hacker, but that doesn't look like a toggle to me... Looks to me like passing in a non-zero value turns SAM on, and passing in 0 turns it off. At least that's what I was seeing last night when I tested it out. I hacked up the sam.c code from riocar.org to set/read SAM status (after I added the GETSAM ioctl) and it wasn't working like a toggle...

what you appear to be doing is affecting the player-ttsd balance.

Yeah, but it seems to be working okay, I don't think it scales the background music down unless a PCM sample is playing... I don't think it's losing fidelity under normal use. Try it out and tell me if I'm wrong...
Posted by: genixia

Re: Working TTS on the player (using flite) - 24/11/2002 12:14

IANA Kernel Hacker, but that doesn't look like a toggle to me.

You're right, I didn't really mean to put it that way...what I meant to say is that the player just toggles, and keeps the state internally, ie, it never reads that state...But I think we'd already covered that ground..

Not enough coffee.

I'm going to try that kernel out..
Posted by: tonyc

Re: Working TTS on the player (using flite) - 25/11/2002 08:52

I'm going to try that kernel out..

Ok, let me know how it works for you. If it's well-received I'll send it Mark's way for inclusion in Hijack. Maybe he'll have some input on a better solution for the SAM problem.
Posted by: tms13

Re: Soft Audio Mute - 26/11/2002 11:58

In reply to:

OK, can anyone think of a legitimate reason why the Empeg player app needs to set Soft Audio Mute when the player pauses?


I'd say it's to avoid transients, and possibly also if the relevant code is shared with Aux and/or Tuner modes - I'm guessing that Mute won't work properly if you ignore SAM in those modes.
Posted by: snoopstah

Re: Working TTS on the player (using flite) - 26/11/2002 15:53

OK, all hell breaks loose when I try and install 1.0a3...


Remounting filesystem read-write...done
Creating fifo...mkfifo: cannot make fifo `/usr/local/ttsd': No such file or directory
done
Creating /usr/local/bin to hold binaries...done
Installing binaries...mv: /usr/local/bin/flite: No space left on device
mv: /usr/local/bin/ttsd: No space left on device
done
Installing launcher...mv: /etc/preinit.d/M10ttsd: No space left on device
done
Remounting filesystem read-only...done
Launching ttsd..../install: /etc/preinit.d/M10ttsd: Permission denied
done

./install: /usr/local/ttsd: Read-only file system
Installation complete.


Looks like I'm having lack of space issues, but also some other problems, as it couldn't make the fifo thingy.

Any ideas where to even start fixing this?

Edit: to clarify, I used this installation method, as posted earlier:


rwm
mkdir /drive0/src
(upload ttsd-1.0a1.tgz to that dir)
cd /drive0/src
tar zxvf ttsd-1.0a1.tgz
cd ttsd-1.0a1
./install


Cheers,

A.
Posted by: genixia

Re: Working TTS on the player (using flite) - 26/11/2002 16:58

Yeah, the install is flawed. Flite is too big to live on the root partition.
Posted by: TheAmigo

Re: Working TTS on the player (using flite) - 27/11/2002 01:56

The installer was a pretty quick hack. The original release had many files and it would've been a pain to do by hand. As I was writing the installer, I was thinking there were many things that could go wrong... looks like you found a few

Creating fifo...mkfifo: cannot make fifo `/usr/local/ttsd': No such file or directory

I guess /usr/local doesn't exist by default... I'll have the installer check that first.

Installing binaries...mv: /usr/local/bin/flite: No space left on device

The installer was written for 1.0a1 and hasn't been updated. Alpha 1 used the 8KHz version of flite and now it uses the 16KHz which is 2M larger. That's enough that it could squeeze by on the root partition before, but not anymore.


I'll have to change that to install on a music partition now. I remember another thread recently talking about a standardized use of directories and partitions on the player. Rather than add to the confusion, I'd like to have it default to installing in a standard place. Was there any consensus reached?

Personally, I'd choose to install everything in /usr/local with binaries in /usr/local/bin. If it doesn't exist, then create something on /drive0 (or 1) called usr_local and make /usr/local a symlink to it. Then installers for all these hacks and add-ons we have can install in /usr/local (creating a sub dir if they want, or just dropping a binary in /usr/local/bin). Users would be free to make /usr/local be a symlink to wherever they want and it's still easy for the developers to write installers. Sound reasonable?

Or maybe this has all been discussed before and I've just not kept up with the msg boards.
Posted by: genixia

Re: Working TTS on the player (using flite) - 27/11/2002 07:08

Possible raw install locations....if they exist and have space. After that try checking for pre-existing /usr/local.

/programs0/ttsd
/programs1/ttsd
Posted by: loren

Re: Working TTS on the player (using flite) - 27/11/2002 10:50

wow. i say we need TTS after reading the phatbox thread, go away for a week, come back, and we have TTS. You guys are amazing.

*but can it read menu items?* =]
Posted by: tonyc

Re: Working TTS on the player (using flite) - 27/11/2002 11:19

*but can it read menu items?* =]

Believe it or not that was going to be my next request... But It seems to me that screen-scraping menus and playlist names isn't all that appealing of an option, so we might have to start thinking along the lines of a player app modification where it sends out a little notify messages to the serial port, which Hijack could then intercept. Which means we'd have to wait for the next release of the software. I thought about possibly having the kernel keep track of what menu item it "thinks" you're on, but that's way too error-prone. Mark is usually pretty inventive when it comes to how the kernel can snoop in on what the player is doing, so maybe he has some better ideas...

Incidentally, the wheels for this TTS thing have been turning for quite some time... It's not like all this work was done in a week.
Posted by: genixia

SAM done 'right' - 27/11/2002 17:05

Tony, apply this patch *over* your previous patch... it re-enables the SAM ioctl, unmutes (brute-force) SAM during overlay use, and restores the player SAM setting afterwards.

There's still some stuff that should be done in this area - for instance brute-forcing the unmute should be config.ini-able, but I can live with it as-is..




diff -Naru -X dontdiff linux-hj300+overlay/arch/arm/special/empeg_audio3.c linux-hj300+overlay+samfix/arch/arm/special/empeg_audio3.c
--- linux-hj300+overlay/arch/arm/special/empeg_audio3.c Sat Nov 23 17:15:26 2002
+++ linux-hj300+overlay+samfix/arch/arm/special/empeg_audio3.c Wed Nov 27 18:54:31 2002
@@ -121,6 +121,7 @@

int audio_overlay_bg_volume = AUDIO_OVERLAY_BG_VOLUME_MAX;
signed short audio_zero_sample[ AUDIO_BUFFER_SIZE/2 ] = { 0 };
+extern int sam;

/* Number of audio buffers that can be in use at any one time. This is
two less since the inactive two are actually still being used by
@@ -1228,8 +1229,18 @@
static int iSwitchToPCM = 0;
static int iFadeVolumeUp = 0;
static int iStoredVolume = 0;
+ static int iSam = 0; // Did we change SAM?
int iPreviousOverlayUsed = audio_overlay.used;
audio_dev *dev=&audio[0];
+
+ if ( audio_overlay.used > 0 && !iSam ) {
+ iSam = 1;
+ empeg_mixer_setsam(0); // Disable SAM whilst overlay is active.
+ }
+ else if ( audio_overlay.used == 0 && iSam ) {
+ iSam = 0;
+ empeg_mixer_setsam(sam); // Restore player's SAM setting.
+ }


if( empeg_mixer_get_input() != 1 ) // INPUT_PCM
diff -Naru -X dontdiff linux-hj300+overlay/arch/arm/special/empeg_mixer.c linux-hj300+overlay+samfix/arch/arm/special/empeg_mixer.c
--- linux-hj300+overlay/arch/arm/special/empeg_mixer.c Tue Nov 26 22:06:14 2002
+++ linux-hj300+overlay+samfix/arch/arm/special/empeg_mixer.c Wed Nov 27 18:47:33 2002
@@ -116,6 +116,7 @@
static struct empeg_eq_section_t eq_current[20];
static int eq_section_order[20];
static int mixer_compression = 0;
+ int sam;
static unsigned int eq_last[40];
static unsigned int eq_reg_last = 0;
static unsigned int radio_sensitivity;
@@ -621,11 +622,13 @@
}
case EMPEG_MIXER_SET_SAM:
{
- int sam;
+ /*int sam; Now global */

copy_from_user_ret((void *) &sam, (const void *) arg,
sizeof(int), -EFAULT);

+ empeg_mixer_setsam(sam);
+ /*
if(sam) dsp_write(Y_switch, 0);
else dsp_write(Y_switch, 0x5d4); // 4.6ms

@@ -634,7 +637,7 @@
": mixer_ioctl EMPEG_MIXER_SET_SAM %d\n",
sam);
#endif
-
+ */
return 0;
}
case EMPEG_MIXER_RAW_I2C_READ:
@@ -873,6 +876,18 @@
#endif
}

+void empeg_mixer_setsam(int on)
+{
+ if(on) dsp_write(Y_switch, 0);
+ else dsp_write(Y_switch, 0x5d4); // 4.6ms
+
+#if MIXER_DEBUG
+printk(MIXER_NAME
+ ": mixer_ioctl EMPEG_MIXER_SET_SAM %d\n",
+ sam);
+#endif
+}
+
int empeg_mixer_get_input()
{
return mixer_global.inputInternal;
@@ -1220,7 +1235,9 @@
(void) empeg_mixer_setvolume(vol);
}

-/*static*/ int empeg_mixer_setvolume(/*mixer_dev *dev,*/ int vol)
+
+/*static*/
+int empeg_mixer_setvolume(/*mixer_dev *dev,*/ int vol)
{
hijack_current_mixer_volume = vol;
dsp_write(Y_VAT, volume_table[vol].vat);
diff -Naru -X dontdiff linux-hj300+overlay/arch/arm/special/empeg_mixer.h linux-hj300+overlay+samfix/arch/arm/special/empeg_mixer.h
--- linux-hj300+overlay/arch/arm/special/empeg_mixer.h Sat Nov 23 17:15:26 2002
+++ linux-hj300+overlay+samfix/arch/arm/special/empeg_mixer.h Wed Nov 27 16:47:39 2002
@@ -30,4 +30,6 @@
int empeg_mixer_setvolume(int vol);
int empeg_mixer_getvolume(void);

+void empeg_mixer_setsam (int on);
+
#endif
Posted by: tonyc

Re: SAM done 'right' - 27/11/2002 20:28

Veddy intedesting... I hadn't thought about doing it that way. I'll check it out!
Posted by: snoopstah

Re: Working TTS on the player (using flite) - 28/11/2002 09:58

Well, after fiddling about with it for about 30 minutes (linux scripting is not my forte), it works! Quite cool, to say the least!

When I run it when music is playing though, using echo hello world > /usr/local/ttsd, it doesn't lower the music volume and say the text, it kind of interlaces the speech and music and goes all juddery. Is this because I just have the standard version of hijack without some of these fancy patches?

And, the most important question - can I get a binary of the 'pico' text editor that works on the empeg? It's the one editor I find really easy to use, and currently I'm FTPing files back and forth from my PC to edit them!
Posted by: tonyc

Sweet. - 29/11/2002 21:35

genixia, you da man. Works great. I think we're almost ready to submit this one for inclusion in Hijack.

Mark did say he wanted someone to change the patch to hold off on allocating and initializing the overlay buffers until the device is first used, so I made that change. I'll attach a new patch which goes against a plain hijack v300 kernel and has your setsam changes and the delayed allocation of the overlay buffers, as well as some conditionally-compiled debug statements.

The one thing I'm a little unhappy with is that the PCM output seems really quiet. I understand why, I mean, it's only scaling down the volume of the background music, and not increasing the volume of the PCM sound. So in theory the PCM will output at a maximum to 50% of the Empeg's volume setting.

I'm nowhere near slick enough to mess with the ASM code he has in the patch to try to find some way of scaling the foreground sound... I tried just multiplying the sample values but I got clipping and no discernable volume increase. Clearly not the way to go.

So the logical solution seems to be to:
1) Fade the background down
2) After it's faded, increase the player's volume with an empeg_mixer_setvolume call.
3) Play the sample
4) Once the sample is done, bring the player's volume back to normal.
5) Fade the BG back up to it's original state.

And that's what Kim's code *looks* like it's doing... BUT... The weird thing is, when I enable AUDIO_OVERLAY_DEBUG, I notice that, while the "audio_overlay_bg_volume" scaling factor is being used, the Empeg's volume setting itself didn't seem to be getting changed anywhere. Setting MIXER_DEBUG in empeg_mixer.c confirms this. empeg_audio3.c has two flags "iSwitchToPCM" and "iFadeVolumeUp" which look like they should be doing something, but they don't appear to be doing anything at all. I don't follow how these flags get triggered.

So, any thoughts on how we can get PCM samples to play at a louder volume, particularly by controlling the player's volume setting? I'm not sure exactly why none of Kim's code for increasing/decreasing the mixer volume is getting called...

If we can find some way to have the mixer volume increased by a configurable level when PCM sounds are playing, I think we're ready to submit the patch for Hijack. Scaling down the PCM doesn't seem to be good enough. Whaddya think?
Posted by: tonyc

Re: Sweet. - 29/11/2002 21:36

Whoops, forgot the patch.
Posted by: TheAmigo

Re: Working TTS on the player (using flite) - 14/12/2002 10:34

I haven't had time to work on this at all since v1.0a3 and I'm gonna be away from the bbs for a couple months.

If someone else is interested in continuing development, please feel free to do so. You just need the source to flite and my diffs which are included in the ttsd package. As the thread's been pretty quiet I wouldn't be surprised if nobody did... in which case I'll resume work on it in a few months.
Posted by: tonyc

Re: Working TTS on the player (using flite) - 14/12/2002 12:14

Well, as you know, I'm working on text-to-speech in emptriv. Right now 1.0a3 is performing rather well, but if I see anything I want to change or improve on in the next month or two, I'll hack at it. Getting the pcmplay and sample rate stuff into flite was really a big win, having the shell script wrapper isn't so bad, but if it's causing problems, I'll see what I can do about improving on it.

Hope your time away is the result of something fun and not work related!
Posted by: TheAmigo

Re: Working TTS on the player (using flite) - 18/02/2003 01:33

Ok, I've started working on this again.

With a bit of hacking, it works well using IrOBEX. I'm now working on a better installer. I'll prolly have it try to detect if Empire is installed and link up with that when it runs.

To get everything I wanted (emphatic, empire and ttsd) running at the same time, I had to set the ReserveCache to 45. I didn't try any other values as that seems to work well.

I hope to release 1.0a4 by this weekend and maybe even 1.0b1 next week.