[Clam-devel] streaming SDIF files

[Greg Kellum]

Hi Xavier,

I figured out what the problem was a couple of hours ago.  I hadn't  
called CanConsumeAndProduce() before calling SMSSynthesis and the  
audio outputs.

It's a bit strange though.  Given the names of the methods, one would  
assume that if these objects couldn't consume and produce output that  
they'd throw an exception, but it seems that instead the objects  
continue to consume and produce anyway;  they just do so out of sync  
with one another...  (Or so it seems...)  What exactly do these  
CanConsumeAndProduce() methods do?

Best,
Greg


On Jul 2, 2007, at 7:37, Xavier Amatriain wrote:

> Greg, another "common" problem when using SMSSynthesis in stream is  
> failing to update the CurrentTimeControl in that class. This is  
> needed to generate the
> correct phase in the PhaseManagement processing. If you don't  
> update this you will get artifacts.
>
> Greg Kellum wrote:
>> Hi Xavier and Pau,
>>
>> There actually shouldn't be any problem with the configuration of  
>> SMSSynthesis.  I dumped the configuration of the SMSAnalysisCore  
>> and SMSSynthesis objects in the SMSTools application to XML files,  
>> and I have used these files to resynthesize a WAV from an SDIF  
>> file without any problems when I was using Segments.  The problem  
>> I mentioned just sprung up when I started streaming the SDIF  
>> file.  But nonetheless, I just tried a couple of alternative hop  
>> sizes, but it didn't help.  When you look at the resynthesized  
>> output in an audio editor, one sees sudden jumps / discontinuities  
>> in the audio signal which would imply that a triangular window  
>> isn't being applied to the signal, because if it was, the signal  
>> would be 0 at the window boundaries.  I'm looking at SMSSynthesis  
>> though at the moment to get a better idea of what is happening...
>>
>> ...
>>
>> I just got Pau's mail.  The problem you had running the example  
>> happened because it couldn't find the configuration file  
>> synthesis.xml.  Just move that file out of the directory  
>> SDIFToWavStreaming into its parent directory, and it will find it,  
>> or give the relative path to the file: SDIFToWavStreaming/ 
>> synthesis.xml.  I did that myself locally, but I forgot to add  
>> that moved synthesis.xml file to the SVN repository.
>>
>> By the way so people in CLAM use tabs, not spaces?  I thought it  
>> was the other way around...
>>
>> Best,
>> Greg
>>
>>
>>
>> On 6/29/07, *Xavier Amatriain* <xavier at create.ucsb.edu  
>> <mailto:xavier at create.ucsb.edu>> wrote:
>>
>>     Hi Greg,
>>
>>     > I've been having a problem with artifacts though that seem  
>> to be
>>     > coming from the overlapping of windows.  My guess is that  
>> either a
>>     > triangular window is not being applied to the audio windows  
>> before
>>     > they are being overlapped or that the step-size is not correct.
>>     I am almost sure that your problem is with the hop/size. If  
>> you use
>>     SMSSynthesis it is very unlikely that the triangular window is  
>> not
>>     applied.
>>     > But even though I've played around with a lot of different  
>> parameter
>>     > values, I can't seem to make the problem go away.  Can someone
>>     tell me
>>     > where exactly this overlap-adding is supposed to be taking  
>> place?
>>     > Which class is responsible for it?
>>     The OverlapAdd takes place in the SMSSynthesis class lines 260  
>> and
>>     268:
>>
>>     http://www.clam.iua.upf.edu/doc/CLAM-devel-doxygen/ 
>> SMSSynthesis_8cxx-source.html#l00200;
>>
>>     And the class responsible for it is the OverlapAdd class
>>
>>     http://www.clam.iua.upf.edu/doc/CLAM-devel-doxygen/ 
>> classCLAM_1_1OverlapAdd.html
>>
>>     A rule of thumb: synthesis hopsize and framesize should both be
>>     equal to
>>     analysis hopsize. (Synthesis hopsize defines how much the
>>     triangular window advances and framesize is half of the  
>> triangular
>>     window size. Note that neither of them have anything to do  
>> with the
>>     analysis window size).
>>
>>     Hope it helps.
>>
>>     _______________________________________________
>>     Clam-devel mailing list
>>     Clam-devel at llistes.projectes.lafarga.org
>>     <mailto:Clam-devel at llistes.projectes.lafarga.org>
>>     https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/ 
>> clam-devel
>>
>>
>> --------------------------------------------------------------------- 
>> ---
>>
>> _______________________________________________
>> Clam-devel mailing list
>> Clam-devel at llistes.projectes.lafarga.org
>> https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/ 
>> clam-devel
>>
>
>
> _______________________________________________
> Clam-devel mailing list
> Clam-devel at llistes.projectes.lafarga.org
> https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam- 
> devel