From andrew.gaydenko on July 30, 2011 05:05:06

To illustrate meters behavior, I have attached two images with HDSP-mixer for both cases - playing back with gst-launch and with clementine.

Left pair in middle row shows application output levels, two right pairs in bottom row shows hardware output levels.

Attachment: 24mixer01.png 24mixer02.png

From andrew.gaydenko on July 30, 2011 05:07:14

Application out level shows effective value which is 3 db below for sine signal, this is why you see -103 db.

From andrew.gaydenko on August 01, 2011 05:00:04

@Developers

Just additional empiric info: replacing 24 in 'width=24,depth=24' in gst-launch command with 32 also works as expected, without 16bit dirt at ~ -94db. Pronbably it is good idea to use 32bit as default bit resolution in all the clementine audio chain - the same way as, say, JACK sever and different sound editors do work.

I'm sure backend robustness and perfectness are fundamentals for any audio player. Please, rise the issue priority if you are share my point. Are you? :)

From john.maguire on August 04, 2011 07:42:46

Labels: -Priority-Medium Priority-Low Component-Radio

From andrew.gaydenko on August 04, 2011 07:53:06

John, will you be so kind to find a second to argument priority lowering?
Does the development team reject a postulate "an engine is a heart of a player"?
Can anybody suggest a code place containing the issue reason?
Why the issue is marked as Component-Radio?

Thanks!

From john.maguire on August 04, 2011 08:43:22

I think the number of people who can tell the difference between 24bit flac and more common formats is very low. This is demonstrated well by the fact you had to construct an artificial demo ;-)

Labels: -Component-Radio Component-Sound

From andrew.gaydenko on August 04, 2011 09:33:19

John,

I seriously and many years deal with different aspects of audio hardware design, but my humble habits in English and touch typing prevents from writing a long reasoning, as well it isn't a suitable place for such speculation :-) So, conclusion only: I'm definitely agree with you, it is impossible for almost people to get statistically significant results in blind testing of difference between 16 and 24 bit content. But - and this is the surprise! - this fact (as any other such tests' results) isn't correlated with real day to day music listening and integrated music fan impression. And this conclusion (and of course, I'm far from to be alone here) is a result of very pragmatic investigation of (and designing new) topologies, schematics and so on, and, of course, without accepting those multiple audiophills' myths (starting from silver cables and wood fixture for them).

At any case developer's opinion is a law for end user. So have you a prompt where to dig in to resolve the issue? As with volume scaling, I'll be happy to use the player with few own patches.

From andrew.gaydenko on August 04, 2011 09:50:52

BTW, there is a very common use case regardless hi-res content. Just imagine it is for some reason more handy to use Clementine's volume setting rather amplifier's one. To have an opportunity to listen at comfortable level to all the playlist with different middle tacks' level (different genres, different studios, different music at last :-)) you are forced to set relatively high volume level of amplifier. For "loud" tracks you need significant attenuation - in the player - for such tracks. Having 16 bit chain you will just "eat" some bits from content reducing software level, while card driver, digital stream transport and DAC permit 24 bit stream, and this "16 to 12 bit conversion" can be prevented. As I have already mentioned, that -94db noise is easy to listen to (even with amplifier gain about 5 at my case).

From andrew.gaydenko on August 19, 2011 08:52:49

I understand it isn't common case to have hdspmixer to examine the problem. As a result I have spent few days and nights learning gst and digging in Clementine code :) As a result - a patch is attached. The patch solves both use cases described above. Unfortunately I have the only OS to test (Linux x86_64). Please, test the patch.

Attachment: gstenginepipeline01.patch

From davidsansome on August 19, 2011 09:27:40

Very nice! I'll review the patch later today.

Owner: davidsansome
Labels: PatchAttached

From davidsansome on August 19, 2011 14:03:15

This issue was closed by revision 41a1518 .

Status: Fixed

From davidsansome on August 19, 2011 14:04:28

Works great for me! I've committed your patch with a few extra comments to explain what's happening.
Thanks again for taking the time to do this!

From andrew.gaydenko on August 19, 2011 14:36:32

David, thanks for accepting! - also have verified final variant. Will go to #2111 now (if there is no any strategic objecting)... :-)

From davidsansome on August 19, 2011 14:48:31

Feel free! :) See Engine::Base::MakeVolumeLogarithmic in src/engines/enginebase.cpp for the existing code.

From andrew.gaydenko on August 19, 2011 14:54:34

In fact in that bug comment I have described all changed fragments (very samll and obvious). It is more difficult for me to prepare multifile patch :-)

From andrew.gaydenko on August 21, 2011 10:22:26

David,

In default configuration appsink has infinite queue, and without consumers ("pull-buffer" signal) it just accumulates all buffers. Such behavior just results in memory leak. I have added to the sink properties

g_object_set(G_OBJECT(probe_sink), "drop", TRUE, NULL);
g_object_set(G_OBJECT(probe_sink), "max-buffers", 1, NULL);

and now all seems to be OK - no leak, 16bit consumers do consume what they want :-)

BTW, I have tried (earlier and now again) other plugins (fakesink and identity as main pretenders), but have not found working configurations for them. So, appsink...

(I have attached patch for 2111)