In reply to:

---

Though having a prerecorded TTS file for every song on my empeg seems a little... um... wasteful. I dunno.

---

The voice I used for this TTS Clock program is actually only 8khz at 16-bit mono. We could probably figure out how to upsample this in real-time.

I'll use my library of songs as an example to calculate how much space would be requierd. Assuming you have a library of 4000 songs, and assuming it would take the TTS an average of 6 seconds to announce the title and artist, that would be 240000 seconds of speech. In 8khz 16-bit mono PCM format that would 368 MB to store the prerecorded speech. Yeah, that is a pretty large footprint, but I still have 15GB free on my 40GB player, so its not really that much. I think its worth it to get the highest quality TTS voices working on the empeg.

And if we use some compressed audio format instead of raw pcm, I think the footprint for this would be almost unnoticable.

I mean, it says what the song is right on the screen. How long does it take to read that?

Well considering you're in a moving vehicle, maybe "too long?"

I dunno. I don't think it's a *superb* idea, but sometimes I'll have to look at my display a lot to tell what song is coming on, mainly if it's the kind of song that fades in or doesn't start off with anything discernable (ambient sounds, etc.) I've caught myself thinking it might be nice to have the artist/title announced, but I also think it might be annoying after awhile.

In any event, I am more interested in TTS for the trivia game, and pre-recorded TTS would seem to be a bad idea there.

Yeah, I'm with you there... I don't want to take away from the achievements being made here, but I just can't see the attraction of song announcement. Didn't I stop listening to the radio because of all the stuff that wasn't music?!

That all being said, I think that this would be very useful for playlist browsing, and also for 3rd party apps such as emptriv and GPSapp. Unfortunately I can't see an easy way to make this work for playlist browsing without some support from the Empeg guys in Cambridge. But maybe this effort will help persuade them to do that...

I can also see use for this being called from HJ as an audio version of the 'Details' screen...Press the button and it tells you the trackname, author etc, going through all the details 'til you press the button again to stop it (or it runs out of data). I think I would find that useful..

In reply to:

---

I don't even understand the concept of wanting to have each song announced. I mean, it says what the song is right on the screen. How long does it take to read that? You know what it is anyway.

---

I'll explain my reasons for wanting this so much. I live in Erie, Pennsylvania by Great Lake Erie. We get a lot of "lake effect" snow. We get snow from November to March and a lot of it. I have ahead of me 5 months of driving through snow, ice, slush, and blizzards. I cannot afford to look at my screen for even half a second without risking a serious accident. And even in the summer I have had many close calls looking at my screen waiting for the artist and title to scroll by when I should be looking at the road. Having a library of 4000 songs I simply can't remember what the title of the song or often even the artist is. And even for songs I have heard hundreds of times I often forget the title. But I really want to know what I'm listening to so I would find this a very useful feature, I wouldn't think it to be annoying at all.

from reading the post about the phatbox it seems they they only announce when traversing playlists.

So its not that it will pause and play, next song is <fill in> but when you go to change what playlist is being used it will annonce the name. i think this is what we should target first. and i think the footprint would be small.

To me this is much more usefull and would actually be quite nice. when you want to change what playlist it is using you can do it via push of a remove button and it will read of the playlists as you go through them and you dont have to look at the player.

I totally agree re: snowstorms/weather. It's a safety thing for me. Although, the gee-whiz power would be immense. I'm not a programmer so the 'how' of it isn't too important, half a gig of non-music doesn't bug me in the least.

I'd like the ability to switch it on/off separately for directory navigation and song announcement. I think some may like one, the other, neither or both & so be able to pick via a hijack menu, like voladj.

I'm really excited to see what you guys come up with. I'll wait till it's ironed out a bit first, I'm not very adventurous.

I'm psyched!

-Zeke

I went back and reread what I wrote and it was pretty pissy. I didn't mean to come off like that. Sorry.

OTOH, I understand where you're coming from a little better now. What would be very cool is if you could set it up so that a specific button press would announce the current song. That way you wouldn't have it saying ``Tequila'' and you saying ``Duh!'', but you could request that it say ``Train to Nowhere''.

I thought of another neat feature/use for TTS. Coupled with OBD it could tell you things like your due for an oil change, or when certain fluids are low(gas, oil, tranny, etc.) I'm sure there's lots of other info that can be pulled from OBD that i'm not thinking of that could be periodically (configurable) announced.

In reply to:

---

So if I'm understanding right, the player software is changing a file that the OS doesn't use to determine it's Timezone?

---

The player software shouldn't be modifying files (except when doing a sync, of course). It keeps its own choice of timezone in flash memory, and uses that in conjunction with the TZLIB files to calculate (in libc) the local time for the process.

I'm not sure what you mean by setting a timezone for "the whole system (player software and OS)" - the OS doesn't have any concept of timezone. Timezone is a user-level concept that the kernel doesn't need to know about in order to do its job. Remember that the player's OS is taken from a general-purpose system, where many users may be logged in from different physical locations, and therefore having different timezones in their processes. It's quite common on desktop systems to run two copies of xclock (or similar) in different timezones if you work closely with colleagues in another country.

The issue that arises is that while most programs can read the TZ environment variable to know what timezone to display times in, the player needs a way to change, store and retrieve a user-set timezone, and obviously an environment variable is not suitable for this, as it's not persistent beyond the process. It can't be set in config.ini, as a user may cross timezone boundaries on his or her travels (I'm sure I'm not the only one who's done this). However, reading from config.ini to set TZ in the environment for other programs is probably reasonable for add-on programs, unless we can discover where the player stores its setting.

That last sentence is a challenge to someone, I hope.

In reply to:

---

The player software shouldn't be modifying files (except when doing a sync, of course).

---

If the player isn't modifying anything on the OS side, then how is it setting the time for the OS when I set the time in the player settings?

Basically what i'd like to see (if possible) is the ability to set my timezone in the player software, set the time,and have the player software and the OS time be in sync.

I can tell that right now when setting the time in the empeg settings, the time is getting changed both in the player software and the OS side. I check this by telnetting in and creating a dir and looking at the time it was created. This time is getting set by the player settings, but since the player is using EST and the OS apparently is not, the time is 5 hours off. Unless I set the player TZ to be Universal in which case both are in sync. But as someone else said, this won't account for DST and I think minor other problems down the road.

This will also help with the TTS-clock in it's current state as it is pulling the time from the OS, not the player software. I also think if we are going to pursue further userland apps that will be running on the OS(GPS), the OS time/ZT being in sync with the player software might become more crucial.

In reply to:

---

If the player isn't modifying anything on the OS side, then how is it setting the time for the OS when I set the time in the player settings?

---

That's not modifying files (see - I was careful with my words!). The RTC, like the flash memory, is writable all the time (to a process with sufficient privilege). But remember that even though the player is showing you local time, it's talking UTC behind the scenes to the kernel. I hope this explanation makes sense.

Absolute (UTC) time is a global concept in Unix; the translation of that time to a particular time-zone is each application's responsibility (just as providing messages in the user's language is). Most applications use the library function localtime() which depends on TZ (the environment variable), so they all have the same behaviour. The player software (probably) doesn't use the environment variable, as it keeps its own time zone in persistent (but not file) storage.

I agree that it would be nice for TTS-clock to pull the player's time zone setting from flash memory (or the scratch partition?) and use that, ideally doing so each time it's used. That's what I was hinting at, at the end of my previous post. A skilled empeg hacker (i.e. not me!) might be able to reverse-engineer the player's actions in response to the user's selection of a time zone, by intercepting the right system calls, I think.

Ok, so basically every app running on this would need to (if based on time) set it's own TZ either through a variable to however the player software is doing it? So in the case of checking the creation times of the directories created in telnet, the telnet daemon would need to set it's own TZ or in the bash shell(is that the shell we're using?)?

EDIT: or better yet, as someonle else mentioned previously, everying is a child off of "init". Should we be setting the TZ variable in there, that way everything (that can/will use it) is using the same TZ?

I just thought of another neat feature. If there were a thermometer that could be tied to the serial port and places around the vehicle somewhere, it could tell the current temperature. "Good morning, today is Tuesday, November 19th, the time is now 12:41PM. The current temperature is 14 below zero"

Another stretch (maybe annoying) would be to sync top news headlines and have it read them off on your way to work if you feel so inclined. And maybe if you find a headline you like, press the knob and have it read off the entire article.

This all of course being after the empeg has completely booted and with the music muted.

In reply to:

---

Ok, so basically every app running on this would need to (if based on time) set it's own TZ either through a variable to however the player software is doing it? So in the case of checking the creation times of the directories created in telnet, the telnet daemon would need to set it's own TZ or in the bash shell(is that the shell we're using?)?

---

In principle, yes, each application should do its own timezone processing based on the player's setting (assuming we find where it's stored, of course). In practice, it's straightforward to do so if we can change the implementation in libc that most applications use. We're straying out of my ability here, though!

Using init to set the TZ variable would be a reasonable halfway house. After changing the player's timezone, it wouldn't have any effect on other apps until your next boot, though. I guess most people could live with that.

After changing the player's timezone, it wouldn't have any effect on other apps until your next boot, though.

That's actually the way it is on most Unix systems.

Ok... this project was the first time I had ever FTPed anything to my empeg. Pretty fun, and it worked... except that it reads the time five hours early. I checked my empeg clock and my time zone. This is probably simple...but so am I .

anyone got this error from B10TTS?

mount: proc already mounted
mount: /dev/hda4 already mounted or /drive0 busy
mount: according to mtab, /dev/hda4 is already mounted on /drive0
mount: you must specify the filesystem type
/dev/empeg_state: Device or resource busy

yeah.... I was just about to comment on that one... Seems to me that the B10tts starts 2 times. One time when it should with preinit.d And one time later just before the player starts.
I added my own startup script to have emptriv start at boot. Its a M10 script and since I added it, TTSclock starts twice. First I used the & command behind my M10 script... Wich resulted in TTSclock speaking twice before the player starts. And without it, TTSclock starts the second time when the player is executed. If I delete the M10 script the problem disappears. I had the same problem when using a M10 preinint script with TTSd (flite).

for me, it doesnt start at all. i dont hear sound or anything.

In reply to:

---

for me, it doesnt start at all. i dont hear sound or anything.

---

That makes two of us...
Anyone any ideas?

Check the permissions of the B10tts script? It needs to be executable.

actually i massaged it to play, but now it doubles up.

In reply to:

---

mount: proc already mounted
mount: /dev/hda4 already mounted or /drive0 busy
mount: according to mtab, /dev/hda4 is already mounted on /drive0
mount: you must specify the filesystem type
/dev/empeg_state: Device or resource busy

---

The B10tts script must mount the partitions during bootup. If run from the command line after its already booted it will give the already mounted errors, but nothing bad happens. During bootup your normal init will give you the already mounted errors since B10tts will mount it before init is run, but this is ok also.

As for "/dev/empeg_state: Device or resource busy" that is the setvol program trying to set your volume. I don't know why you are getting that, but if your script works from the commandline, but not during bootup this could be the cause. It is supposed to set the empeg volume from 0 to whatever you had the player volume set to. If it doesn't work the volume will be 0 and you won't hear anything.

Earlier in this thread I mentioned problems with having 'M' scripts on your system with my 'B' script. If you have my B script loaded and you have other M scripts, you should rename all your M scripts to B also to prevent the program from stuttering. Make sure they are alphabetically after B10tts.

did anyone else notice it wasn't able to say "21st" this morning?

If you have my B script loaded and you have other M scripts, you should rename all your M scripts to B also to prevent the program from stuttering. Make sure they are alphabetically after B10tts.

I've noticed that that's a problem, but why is that? At first glance, it would seem to be a bug in preinit, but I can't tell for sure.

In seting up ttsd, I named its startup script M10ttsd because it needs access to files. For people with both ttsclock and ttsd, it needs to be called B20ttsd. That would then mean that my installer has to check to see if ttsclock is installed so it can name ttsd startup script accordingly. Conversely, if ttsclock is installed after ttsd, then ttsd's script needs to be renamed.

Is there a better way to do this?

I only ever intended for there to be one B script. It stands for ``block'', which means that it's intended to block at the end of the script, probably by running the player itself.

If you're not going to do that, there should be no functional difference between an N and a B script, other than they run as two separate queues.

Ah, I've never had more than one B script so I've never really played with that.

I'm still not sure I understand why the B script gets run a second time when there's an M present. After ttsclock runs (B10tts) and says the time, then ttsd runs (M10ttsd) which includes a 10 second sleep. After the 10 second sleep, M10ttsd finishes and B10tts is run again and tries to say the time while the player is now playing. I would have expected each script to only be run once.

That's probably a bug, but I never caught it because that's not the way I intended it to be used. I'll take a look at it.

Me too! Me too! This morning I thought "maybe" it didn't say '21st', but I at lunch today I know I didn't hear it.

-Chuck

did anyone else notice it wasn't able to say "21st" this morning?

Yes, same here.