[Clam-devel] problem with multiChannelAudioFileWriter

[globot]

sorry, I didn't make a reply to the mailing list first (and yesterday i 
took a day off)


David García Garzón a écrit :
> On Dilluns 31 Març 2008, globot wrote:
>> David García Garzón a écrit :
>>> On Dilluns 31 Març 2008, globot wrote:
>>>> hi,
>>>>
>>>> 好久不见, long time not see :)
>>>> recently I have seen a strange problem with the
>>>> MulltyChannelAudioFileWriter, my old code for recording sound is 
>>>> simple
>>>> and was working just fine for a while but since... I don'tt know 
>>>> when it
>>>> don't work anymore and I can't record.
>>>>
>>>> what i do :
>>>> > cfg2.SetTargetFile( (const char *)file );
>>>> > cfg2.SetSampleRate(48000);
>>>> > cfg2.SetNChannels(2);
>>>> >
>>>> > writer = new CLAM::MultiChannelAudioFileWriter( cfg2 );
>>>> >
>>>> > network->AddProcessing("AudioFileWriter", writer);
>>>> > network->ConnectPorts("AudioMixer_AirL.Output Audio",
>>>>
>>>> "AudioFileWriter.Channel #0");
>>>>
>>>> > network->ConnectPorts("AudioMixer_AirR.Output Audio",
>>>>
>>>> "AudioFileWriter.Channel #1");
>>>>
>>>> > network->Start();
>>>>
>>>> I always get an error of type :
>>>> > ##########################################################
>>>> > ################### ASSERTION FAILED #####################
>>>> > ##########################################################
>>>> > At file scons/libs/audioio/src/PCMAudioStream.cxx line 99
>>>> > Cannot open file '/music/test/0_20080331_1154.aif' for writing!!!
>>>>
>>>> plus, if i look the MultiChannelAudioFileWriter configuration error i
>>>> got a return false because => "No file selected"
>>>>
>>>>
>>>> the problem is that before it was working just fine, the /music
>>>> partition is mounted correctly with write permission, and if i load 
>>>> the
>>>> network with NE, it work well.
>>>> My code haven't change for months, the only tow think i did was, crypt
>>>> the /music partition with a heavy encryption (but work well with 
>>>> NE) and
>>>> commit the last CLAM svn version one week ago (from old svn 1.1.1)
>>>>
>>>> an other thing that trouble me a little is that if i want to 
>>>> reconfigure
>>>> an existing multiChannelFileWriter object, I got a segfault with no
>>>> assert. i try to do it on the reader and work well, but on the writer
>>>>
>>>> the fallowing code cause a crash :
>>>> > if (!network->ConfigureProcessing("AudioFileWriter", cfg2)) // <=
>>>>
>>>> segfault here
>>>>
>>>> > {
>>>> > fprintf(stderr, "Error : can not configure AudioFileWriter\n");
>>>> > return;
>>>> > }
>>>>
>>>> I tried to revert CLAM to my old version, but there is no effect, 
>>>> still
>>>> produce error.
>>>> an other thing strange is that the header of the audio file is written
>>>> (in my case aiff file header)
>>>>
>>>> do you have any clue ? I don't know exactly where to search, i 
>>>> think the
>>>> write access is denied because the file might be locked, but why ?
>>> This is my bad smell:
>>>> > cfg2.SetTargetFile( (const char *)file );
>>> Why do you need to cast to const char *? What is 'file'?
>> bah... this is a QString object so I cast it (this is a QT3 application)
>> ... It worked well before i don't think this is the problem. Plus if i
>> print what the sndfile open function receive it look good... but the
>> function fail to open => sf_open in PCMAudioStream.cxx line 94
>>
>> I forget I also install SCIM with chinese as default language but it
>> shouldn't be a matter since there is the same issue on other machine
>> where i didn't install it.
>>
>> I made a little strace of the execution and the file is correctly open,
>> the header is writen, then the file is closed and clam assert is
>> triggered .... I presume it is the sf_open that will call open and write
>> the header but for some reason it will not return what it should form
>> CLAM => mFileHandle.
>>
>> for me it look a little strange. I will continue my investigation....
>
> You cannot simply cast a Qt3 QString! you have to obtain the buffer!
what do you mean by "obtain" the buffer, a const pointer should be 
enough since there is no use to modify the buffer, casting a QString to 
a const char* is perfectly valid, there is special things (operator) in 
QT3 to make it work well...
> In qt3 I normally used the ascii method but if you are using encodings 
> consider using utf-8 related functions. UTF8 is the safest encoding. 
> It represents any character, and it still can be is a valid zero ended 
> string.
>
You can also use ascii or utf-8 but the result is the same in that case, 
i tried it to be sure, but it does not change the result...

> Indeed, the comunication between clam and libsndfile and the like 
> seems not to support well encodings. For example i am unable to open 
> songs with non ascii spanish symbols. Try with some file with just 
> ASCII in the name. If you still experience problems there should be a 
> different issue. Any help in solving the unicode hell will be 
> appreciated.
I am aware of this issue but this is not the problem in this case, I Had 
in past some problem opening file with accent... But again here i tried 
to print the name of file drectly given to sf_open function and there is 
no mistake the name of file is good (contain only ascii letter anyway, 
it is generated from date)

if it was an encoding problem, the file would not be created, and the 
header written. There must be something else.... like concurrent IO 
perhaps ...