Re: Subject: Albums under a label recorded and/or mixed with Linux

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, September 29, 2010 5:44 am, fons@xxxxxxxxxxxxxxx wrote:
> On Tue, Sep 28, 2010 at 06:44:09PM -0700, Patrick Shirkey wrote:
>
>> On Tue, September 28, 2010 8:22 am, fons@xxxxxxxxxxxxxxx wrote:
>>
>> > The implementation is fundamentally wrong. Just send a sine wave
>> through
>> > it, measure the result and ask yourself how a *filter* could ever
>> produce
>> > the broadband junk that this one is adding.
>>
>> Well if this is the case the implementation needs optimisation. That
>> doesn't change the fundamental nature of the design choice.
>
> Thas nothing to do with optimisation. The algorithm is wrong. It does
> not do what you think it does and what the designers probably intended
> it to do. The correct one is not much different, but differs in some
> essential points.
>
>> Don't you mean an optimised implementation of the filter?
>
> No. I mean a correct implementation.
>
>> > My concerns are not about the optimisation. For there isn't any. I
>> repeat:
>> > the implementation is fundamentally wrong, the method used does not
>> only
>> > filter but it also adds distortion, and most of the CPU power used by
>> the
>> > filter is used just to reduce the problems that result from this.
>> >
>>
>> How can it be fundamentally wrong if all linear convolution operations
>> can
>> be expressed in the the transformed domain, and vice versa.
>
> The fact that this *can* be done does not imply it *has* been done
> correctly in this case.
>
>> If there is a problem it is not due to the fundamental nature of the
>> linear filter.
>
> I'd suggest you stop calling this a linear filter for it isn't.
>
>> But I will query your analysis first because it may be that we are
>> talking
>> at cross purposes.
>>
>> IMO what you have identified is the potential for optimising the code.
>
> No. Although a correct implementation would indeed use less CPU.
>
>> This is definitely something that should be addressed if it indeed turns
>> out you are correct in your analysis.
>>
>> Although I have strong reservations given that 3 different DSP engineers
>> with qualitatively more experience than you can justify this design
>> choice.
>
> Then let them speak up. I've posted the technical arguments before and
> nor you nor any of your experts has so far commented on them. And as to
> my level of experience, I don't think you have any correct idea of that.
>
> I've a nice collection of measurement results for Jamin, maybe I'll
> publish a few of them and then your experts can try to explain them.
>

I am only interested in figuring out wtf is the real problem with jamin. I
don't doubt that you have found something credible and you can trust in
the fact that your concerns are being looked into from here.

If you want to know more details I will be happy to provide more
information off list.

Otherwise in the interests of keeping a relatively convivial tone I would
like to thank you for spotting the flaws that you have found.



-- 
Patrick Shirkey
Boost Hardware Ltd.

_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/listinfo/linux-audio-user


[Index of Archives]     [Linux Sound]     [ALSA Users]     [Pulse Audio]     [ALSA Devel]     [Sox Users]     [Linux Media]     [Kernel]     [Photo Sharing]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux