#126819 - 23/11/2002 19:07
Re: Working TTS on the player (using flite)
[Re: tonyc]
|
Carpal Tunnel
Registered: 08/02/2002
Posts: 3411
|
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?
_________________________
Mk2a 60GB Blue. Serial 030102962
sig.mp3: File Format not Valid.
|
|
Top
|
|
|
|
|
#126820 - 23/11/2002 19:52
Re: Working TTS on the player (using flite)
[Re: genixia]
|
Carpal Tunnel
Registered: 08/02/2002
Posts: 3411
|
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 
_________________________
Mk2a 60GB Blue. Serial 030102962
sig.mp3: File Format not Valid.
|
|
Top
|
|
|
|
|
#126821 - 23/11/2002 20:26
Re: Working TTS on the player (using flite)
[Re: genixia]
|
carpal tunnel
Registered: 27/06/1999
Posts: 7058
Loc: Pittsburgh, PA
|
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?
|
|
Top
|
|
|
|
|
#126822 - 23/11/2002 21:14
Re: Working TTS on the player (using flite)
[Re: genixia]
|
carpal tunnel
Registered: 27/06/1999
Posts: 7058
Loc: Pittsburgh, PA
|
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...
Edited by yn0t_ (23/11/2002 21:17)
|
|
Top
|
|
|
|
|
#126823 - 23/11/2002 21:58
Re: Working TTS on the player (using flite)
[Re: tonyc]
|
Carpal Tunnel
Registered: 08/02/2002
Posts: 3411
|
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
Edited by genixia (23/11/2002 22:00)
_________________________
Mk2a 60GB Blue. Serial 030102962
sig.mp3: File Format not Valid.
|
|
Top
|
|
|
|
|
#126824 - 23/11/2002 22:39
Re: Working TTS on the player (using flite)
[Re: genixia]
|
enthusiast
Registered: 14/09/2000
Posts: 363
|
@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.
|
|
Top
|
|
|
|
|
#126825 - 24/11/2002 01:56
Re: Working TTS on the player (using flite)
[Re: genixia]
|
carpal tunnel
Registered: 27/06/1999
Posts: 7058
Loc: Pittsburgh, PA
|
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?
|
|
Top
|
|
|
|
|
#126826 - 24/11/2002 09:43
Re: Working TTS on the player (using flite)
[Re: tonyc]
|
enthusiast
Registered: 14/09/2000
Posts: 363
|
@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.
|
|
Top
|
|
|
|
|
#126827 - 24/11/2002 10:04
Re: Working TTS on the player (using flite)
[Re: TheAmigo]
|
carpal tunnel
Registered: 27/06/1999
Posts: 7058
Loc: Pittsburgh, PA
|
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...
|
|
Top
|
|
|
|
|
#126828 - 24/11/2002 11:13
Re: Working TTS on the player (using flite)
[Re: tonyc]
|
Carpal Tunnel
Registered: 08/02/2002
Posts: 3411
|
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
_________________________
Mk2a 60GB Blue. Serial 030102962
sig.mp3: File Format not Valid.
|
|
Top
|
|
|
|
|
#126829 - 24/11/2002 11:35
Re: Working TTS on the player (using flite)
[Re: genixia]
|
carpal tunnel
Registered: 27/06/1999
Posts: 7058
Loc: Pittsburgh, PA
|
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...
|
|
Top
|
|
|
|
|
#126830 - 24/11/2002 12:14
Re: Working TTS on the player (using flite)
[Re: tonyc]
|
Carpal Tunnel
Registered: 08/02/2002
Posts: 3411
|
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..
_________________________
Mk2a 60GB Blue. Serial 030102962
sig.mp3: File Format not Valid.
|
|
Top
|
|
|
|
|
#126831 - 25/11/2002 08:52
Re: Working TTS on the player (using flite)
[Re: genixia]
|
carpal tunnel
Registered: 27/06/1999
Posts: 7058
Loc: Pittsburgh, PA
|
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.
|
|
Top
|
|
|
|
|
#126832 - 26/11/2002 11:58
Re: Soft Audio Mute
[Re: tonyc]
|
old hand
Registered: 30/07/2001
Posts: 1115
Loc: Lochcarron and Edinburgh
|
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.
_________________________
Toby Speight
030103016 (80GB Mk2a, blue)
030102806 (0GB Mk2a, blue)
|
|
Top
|
|
|
|
|
#126833 - 26/11/2002 15:53
Re: Working TTS on the player (using flite)
[Re: TheAmigo]
|
enthusiast
Registered: 07/01/2002
Posts: 339
Loc: Squamish, BC
|
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.
Edited by snoopstah (26/11/2002 15:55)
|
|
Top
|
|
|
|
|
#126834 - 26/11/2002 16:58
Re: Working TTS on the player (using flite)
[Re: snoopstah]
|
Carpal Tunnel
Registered: 08/02/2002
Posts: 3411
|
Yeah, the install is flawed. Flite is too big to live on the root partition.
_________________________
Mk2a 60GB Blue. Serial 030102962
sig.mp3: File Format not Valid.
|
|
Top
|
|
|
|
|
#126835 - 27/11/2002 01:56
Re: Working TTS on the player (using flite)
[Re: snoopstah]
|
enthusiast
Registered: 14/09/2000
Posts: 363
|
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.
|
|
Top
|
|
|
|
|
#126836 - 27/11/2002 07:08
Re: Working TTS on the player (using flite)
[Re: TheAmigo]
|
Carpal Tunnel
Registered: 08/02/2002
Posts: 3411
|
Possible raw install locations....if they exist and have space. After that try checking for pre-existing /usr/local.
/programs0/ttsd
/programs1/ttsd
_________________________
Mk2a 60GB Blue. Serial 030102962
sig.mp3: File Format not Valid.
|
|
Top
|
|
|
|
|
#126837 - 27/11/2002 10:50
Re: Working TTS on the player (using flite)
[Re: genixia]
|
carpal tunnel
Registered: 23/08/2000
Posts: 3826
Loc: SLC, UT, USA
|
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?* =]
|
|
Top
|
|
|
|
|
#126838 - 27/11/2002 11:19
Re: Working TTS on the player (using flite)
[Re: loren]
|
carpal tunnel
Registered: 27/06/1999
Posts: 7058
Loc: Pittsburgh, PA
|
*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.
|
|
Top
|
|
|
|
|
#126839 - 27/11/2002 17:05
SAM done 'right'
[Re: tonyc]
|
Carpal Tunnel
Registered: 08/02/2002
Posts: 3411
|
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
_________________________
Mk2a 60GB Blue. Serial 030102962
sig.mp3: File Format not Valid.
|
|
Top
|
|
|
|
|
#126840 - 27/11/2002 20:28
Re: SAM done 'right'
[Re: genixia]
|
carpal tunnel
Registered: 27/06/1999
Posts: 7058
Loc: Pittsburgh, PA
|
Veddy intedesting... I hadn't thought about doing it that way. I'll check it out!
|
|
Top
|
|
|
|
|
#126841 - 28/11/2002 09:58
Re: Working TTS on the player (using flite)
[Re: TheAmigo]
|
enthusiast
Registered: 07/01/2002
Posts: 339
Loc: Squamish, BC
|
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!
|
|
Top
|
|
|
|
|
#126842 - 29/11/2002 21:35
Sweet.
[Re: genixia]
|
carpal tunnel
Registered: 27/06/1999
Posts: 7058
Loc: Pittsburgh, PA
|
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?
|
|
Top
|
|
|
|
|
#126844 - 14/12/2002 10:34
Re: Working TTS on the player (using flite)
[Re: TheAmigo]
|
enthusiast
Registered: 14/09/2000
Posts: 363
|
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.
|
|
Top
|
|
|
|
|
#126845 - 14/12/2002 12:14
Re: Working TTS on the player (using flite)
[Re: TheAmigo]
|
carpal tunnel
Registered: 27/06/1999
Posts: 7058
Loc: Pittsburgh, PA
|
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!
|
|
Top
|
|
|
|
|
#126846 - 18/02/2003 01:33
Re: Working TTS on the player (using flite)
[Re: TheAmigo]
|
enthusiast
Registered: 14/09/2000
Posts: 363
|
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.
|
|
Top
|
|
|
|
|
|
Previous Topic
Index