[Bug 441] Review request: traverso - Multitrack Audio Recording and Editing Suite

[RPM Fusion Bugzilla]

http://bugzilla.rpmfusion.org/show_bug.cgi?id=441





--- Comment #14 from Orcan Ogetbil <oget.fedora at gmail.com>  2009-04-27 18:47:46 ---
(In reply to comment #13)
> * Please delete any internal dependency:
> rm -rf src/3rdparty/slv2

OK

> (Rememeber that cmake list slv2 to be >=0.6.1 )
> 
> * Please append a versioned BuildRequirement when relevant.
> 

I don't think we ever had slv2 < 0.6.1 in Fedora but I'll add the versioned
dependency anyways.

> * QT_PHONON_LIBRARY_RELEASE        QT_PHONON_LIBRARY_RELEASE-NOTFOUND
> I'm not sure traverso will use photo, unless it needs qt 4.5.1.
> same for
> QT_QTMOTIF_LIBRARY_RELEASE       QT_QTMOTIF_LIBRARY_RELEASE-NOTFOUND
> I don't know if it is relevant.
> 

I think these are standard cmake checks. Nothing to do with traverso though.

> 
> * Optims, I"ve successfully have built traverso using:
> %{cmake}                                               \
>          -DWANT_MP3_ENCODE=ON                          \
>          -DUSE_SYSTEM_SLV2_LIBRARY=ON \
>          .
> And our CFLAGS were used. But it has also used some "not always available" asm
> optim such as 3dnow. 
> Vector optims seems MacOSX related (not linux on ppc), so the only important
> feature is SSE on x86(_64) (possible with IA64 in theory?)
> 

Yes. Sorry, my explanation was wrong. This should be the correct explanation:
In order to pass the SSE related flags to the compiler, I need to add to the
CXX_FLAGS, that's why I use:
            -DCMAKE_CXX_FLAGS:STRING="${CXXFLAGS}         \
            <bunch of SSE related flags>                  \
            "                                             \

Hint: Look at the quotes.

Obviously, I can't use the DETECT_HOST_CPU_FEATURES feature. I found that the
way I do it is the shortest way. If you have a better solution, please post the
appropriate %cmake command here.

> According to CMakeLists.txt , the DETECT_HOST_CPU_FEATURES rely on
> /proc/cpuinfo and set various definition. It would be better to patch it to 
> use a cmake option, so sse can be enabled by a switch, and the various 
> needed options to be set.
> 
> According to the Fedora guideline, using SSE on x86 is illegal as not all CPU
> have this feature on x86 (despite x86_64 at least have SSE2). If I let you
> build a SSE enabled binary, at least I want a "cmake option" that will avoid
> SSE without disabling x86 conditionalized code. Please forward this upstream 
> if necessary.
> 

If I can solve this issue without a patch, why should I make one?

As for the SSE on x86: this is a DAW, intended for professional use. The
software will not be useful at all for people with older hardware without SSE.
Even my old 32bit AMD Athlon 2000, can't handle DAW usage properly when I
enable multiple tracks and multiple (ladspa, lv2, etc) plugins at once. I don't
think it is worth considering even older hardware. There are more lightweight
programs (such as audacity) for those people.

> To sum-up:
> buildtime autodetection should remains disabled. 
> x86(_64) should be automatically detected according to the _target_cpu been
> used.
> SSE should be enabled by a cmake switch (default on x86_64)
> 

Okay, I can make a patch. But again, why a patch when there is no need?


> Please avoid bundling pre-built pdf documentation , prefer to use the url
> instead!!!
> 

Okay, I'll remove the pdf and add the url.

> Furthermore i've tried to read the pdf (was fly reading actually) and found
> rather hard to see if something needs to be tweaked in
> /etc/security/limits.conf.


It is at the last pages of the pdf file. It involves creation of an audio group
if it is not present, giving special permissions to that group and adding your
username to that group. I don't think adding usernames automatically to a group
in %post is a good idea.

> 
> * Fedora hacking. %{name}-defaults.patch
> I don't understand why changing the number of period would solve things for
> Fedora? Does it, really ? (of course, as i'm using PA, it doesn't solve
> anything).
> 

I don't know why. But it works :)
A similar situation happened with qsynth, where I had to tweak with one of the
default parameters, otherwise it won't work properly.


-- 
Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.