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!

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

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*.

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.

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.

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).

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

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.

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?

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!!!

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.

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.

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.

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!

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.

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?!

huh?

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.

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*

Dude, that really is the best picture ever.

. 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...

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?

<KITT>What you talkin' 'bout Michael?</KITT>

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.

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.

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?

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.

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.

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.

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.