Re: [timidity-talk] very old problem: noise on acoustic piano patches (fwd)

[Florin <rd...@rd...>]

Thanks a lot Eric, I found what the problem was!
I have 2 soundcards, one included on the motherboard with an ALC650 and a PCI 128 Creative Vibra (Ensoniq 1371). I use to use the ALC650 only for mixing, which was pretty OK; but timitity was taking it by default for DSP device. Now I found out that this card's DSP sucks! reading on the net, they say it has a buggy DAC. So I just switched the audio output device to "hw:1" (I'm using ALSA 1.0.2c) and now it works great! How stupid to have this problem for so long! :))
Yeah, the comple problem was in mix.c as I remember, where the voice was undefined when defining SMOOTH_MIXING; it's simple to solve.

There remains only one problem I would have to solve to use timidity as a real time MIDI device.  I've noticed that there is a big delay (up to 2s) between the MIDI notes and the sound synthesis (when using timidity as MIDI sequencer device and a MIDI keyboard, virtual or not). The bigger the sound samples are, the bigger the delay, also depending on the interpolation method, filters, resampling and so on (when I want to use a 128Mb piano soundfont this appears very clearly). I suppose that using MMX/SSE optimisations would change this, but one of the problems might be also swapping or not caching the whole soundfont into the RAM. Could I change this behavior in some way?

If not, that doesn't quite disturb me, cause for the keyboard I can use fluidsynth; on the second soundcard it sounds preytty well too, except some bugs in multiple channels MIDI files which are not a problem for someone playing the piano.

Thanks again!
Florin

Pe 27 Apr 2005, la 02:14, Eric Welsh <ew...@bi...> a scris:

>
>OK, 6th try now, let's see if the stupid automated SpamCop block on
>.wustl.edu has finally filtered through to the sourceforge.net and
>rdslink.ro mail servers....
>
>-Eric
>
>---------- Forwarded message ----------
>Date: Mon, 25 Apr 2005 17:46:11 -0500 (CDT)
>From: Eric Welsh <ew...@bi...>
>Reply-To: ew...@cc...
>To: Florin <rd...@rd...>
>Cc: tim...@li...
>Subject: Re: [timidity-talk] very old problem: noise on acoustic piano
>    patches
>
>> 1) creating the .wav file takes less than half the time that would take
>> to play the MIDI file
>
>The speed of creating the wav file is limited only by CPU speed.
>
>> 2) if one "cat" s the .wav file into /dev/dsp the sound gets played
>> correctly; but since .wav rendering seems to be fast enough, the things
>> should also work in realtime without any problem
>
>> 3) the .wav sound produced with -Ow is crystal clear, but not the sound
>> played with -Os, -Od or -Oe option
>
>Smells like a sound driver problem to me.  I don't know how things work in
>linux, but in Windows there is a similar problem to what you describe.
>Windows automatically upsamples audio to either 44100 or 44800, I don't
>remember which.  Some drivers do a HORRIBLE job with the interpolation, so
>if your playback sampling rate is different from what Windows forces it to
>upsample to, it may sound pretty bad.  The onboard audio for my
>motherboard is one such example.  For instance, playing back at 32000 Hz
>introduces all sorts of harmonic noise that shouldn't be there, isn't in
>the wav file, and isn't there if the wav file is resampled in a high
>quality resampling program to the sampling rate that Windows forces upon
>the drivers.  Do linux sound drivers also force an auto-upsampling?  Does
>cat'ing to /dev/dsp bypass the normal audio driver rendering mechanism?
>
>> How can that be?! something different between the "-Os" and "-Ow"
>> concerning the sound rendering? Some global anti-aliasing existing in
>
>The output to wav *should* be the same as what gets sent to the audio
>driver.  The only difference should be that the rate of the output to
>the audio drivers is throttled so that it doesn't play too quickly (or if
>your CPU is too slow, it will start to drop notes or stutter).  I'm
>guessing it is some sort of audio driver problem?  If it is a problem with
>timidity rendering real time differently than wav, that would be ugly....
>
>> So OK, Eric, you shouldn't worry, the sf2 synthesis works great, the
>> problem is in the output part somewhere. And one info that might be
>> interesting: undefining SMOOTH_MIXING did not cause any noise, at least
>> in what I tried. Maybe it would deserve a command line option. ;)
>
>You need to have the right test cases :)  I have only two after all my
>years of collecting music to test timidity with.  But with these examples,
>it is very clear what the cause of the problem is by looking at the output
>wav file.  Very rapid pan changes and very rapid volume changes will cause
>a pop if SMOOTH_MIXING isn't enabled.  I am concerned that it didn't
>compile correctly when it was undefined, though.  That didn't use to be
>the case....
>
>-Eric
>
>
>-------------------------------------------------------
>SF.Net email is sponsored by: Tell us your software development plans!
>Take this survey and enter to win a one-year sub to SourceForge.net
>Plus IDC's 2005 look-ahead and a copy of this survey
>Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id=105hix
>_______________________________________________
>Timidity-talk mailing list
>Tim...@li...
>https://lists.sourceforge.net/lists/listinfo/timidity-talk