Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use SampleRate type consistently #11904

Merged
merged 24 commits into from
Sep 8, 2023
Merged

Use SampleRate type consistently #11904

merged 24 commits into from
Sep 8, 2023

Conversation

Holzhaus
Copy link
Member

This replaces all remaining occurrences of integer sample rates that I found via git grep and uses the semantic mixxx::audio::SampleRate type instead.

Copy link
Member

@daschuer daschuer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you. I left some comments.

@@ -128,8 +128,8 @@ void FilterEffect::processChannel(
double qmax = 4 - 2 / 0.6 * ratio;
clampedQ = math_min(clampedQ, qmax);
}
pState->m_pLowFilter->setFrequencyCorners(1, lpf, clampedQ);
pState->m_pHighFilter->setFrequencyCorners(1, hpf, clampedQ);
pState->m_pLowFilter->setFrequencyCorners(mixxx::audio::SampleRate(1), lpf, clampedQ);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks confusing. I think using mixxx::audio::SampleRate is wrong here, because it not seems to have the same semantic at "1/x s" like in other cases. It is here just the frequency denominator. It looks like it becomes a double at one point in fidlib.
See also: m_hiFreq(kMinCorner / engineParameters.sampleRate()) {
I so there is more refactoring/testing required. Postpone?
.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but the parameter is named samplerate. What should it be named instead if its not used as a samplerate?

Copy link
Member

@daschuer daschuer Sep 1, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It can be refactored into using our mixxx::audio::SampleRate that is always in samples/s.
Currently it looks like it sets the filter to a 1/s sample rate, which is not the case.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm unsure what you want me to do TBH.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure if we have a common understanding about the issue here. Do we?

I propose to revert the Fidlib related changes here and merge the rest of this PR quickly. This way we can consider the best solution for this issue in a smaller PR < 66 files .

Copy link
Member Author

@Holzhaus Holzhaus Sep 2, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I checked in the fidlib code and the sampleRate parameter is actually passed as double rate parameter of the fid_design() method. In the error handling code, rate is used as the second argument of the error message Frequency of %gHz out of range with sampling rate of %gHz. So it seems indeed the "sampling rate". No idea why we pass just 1 though.

Should I revert the changes nonetheless?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I think we have two options.

  1. Postpone the Fidlib related actions
  2. Use here the real 1/s base sample rate values via our semantic type and adjust the other parameters accordingly.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Undoing all the fidlib-related changes turned out tedious, so I opted for 2. Please have a look at 99e1088.

src/engine/enginevumeter.cpp Outdated Show resolved Hide resolved
src/preferences/dialog/dlgprefsound.cpp Outdated Show resolved Hide resolved
src/preferences/dialog/dlgprefsound.cpp Show resolved Hide resolved
src/soundio/soundmanagerconfig.cpp Outdated Show resolved Hide resolved
Comment on lines +562 to +563
m_pConfig->set(ConfigKey("[Soundcard]", "Samplerate"),
ConfigValue(static_cast<int>(m_config.getSampleRate().value())));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
m_pConfig->set(ConfigKey("[Soundcard]", "Samplerate"),
ConfigValue(static_cast<int>(m_config.getSampleRate().value())));
m_pConfig->setValue<int>(ConfigKey("[Soundcard]", "Samplerate"),
m_config.getSampleRate().value());

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/home/jan/Projects/mixxx/src/soundio/soundmanager.cpp: In member function ‘SoundDeviceStatus SoundManager::setConfig(const SoundManagerConfig&)’:
/home/jan/Projects/mixxx/src/soundio/soundmanager.cpp:563:57: error: call of overloaded ‘ConfigValue(mixxx::audio::SampleRate::value_t)’ is ambiguous
  563 |             ConfigValue(m_config.getSampleRate().value()));
      |                                                         ^
In file included from /home/jan/Projects/mixxx/src/preferences/usersettings.h:6,
                 from /home/jan/Projects/mixxx/src/controllers/midi/midimessage.h:10,
                 from /home/jan/Projects/mixxx/src/control/controlbehavior.h:6,
                 from /home/jan/Projects/mixxx/src/control/control.h:9,
                 from /home/jan/Projects/mixxx/src/control/pollingcontrolproxy.h:6,
                 from /home/jan/Projects/mixxx/src/soundio/soundmanager.h:11,
                 from /home/jan/Projects/mixxx/src/soundio/soundmanager.cpp:1:
/home/jan/Projects/mixxx/src/preferences/configobject.h:83:14: note: candidate: ‘ConfigValue::ConfigValue(double)’
   83 |     explicit ConfigValue(double value);
      |              ^~~~~~~~~~~
/home/jan/Projects/mixxx/src/preferences/configobject.h:82:14: note: candidate: ‘ConfigValue::ConfigValue(int)’
   82 |     explicit ConfigValue(int value);
      |              ^~~~~~~~~~~
/home/jan/Projects/mixxx/src/preferences/configobject.h:73:7: note: candidate: ‘ConfigValue::ConfigValue(const ConfigValue&)’
   73 | class ConfigValue {
      |       ^~~~~~~~~~~

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

okay, Ignore for now. I'll look into it some other time.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've looked into it. The problem is trivial on the surface (uint32_t can't be promoted to int nor double, thus it would be converted and neither conversion ranks better than the other). The problem gets harder when I looked into fixing it. configobject.h is unnecessarily complex with lots of duplicated code due to a lack of separation of concerns (ConfigValue vs ConfigObject::setValue, which type/function is supposed to do the conversion?). I may do some refactoring in the future.

src/soundio/soundmanagerconfig.cpp Outdated Show resolved Hide resolved
src/soundio/soundmanagerconfig.cpp Outdated Show resolved Hide resolved
@@ -128,8 +128,8 @@ void FilterEffect::processChannel(
double qmax = 4 - 2 / 0.6 * ratio;
clampedQ = math_min(clampedQ, qmax);
}
pState->m_pLowFilter->setFrequencyCorners(1, lpf, clampedQ);
pState->m_pHighFilter->setFrequencyCorners(1, hpf, clampedQ);
pState->m_pLowFilter->setFrequencyCorners(mixxx::audio::SampleRate(1), lpf, clampedQ);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but the parameter is named samplerate. What should it be named instead if its not used as a samplerate?

Copy link
Member

@Swiftb0y Swiftb0y left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My comments have been resolved, waiting for LGTM from @daschuer

Copy link
Member

@daschuer daschuer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removing the normalization form the filter seems to work. Thank you.
I have left two additional comments.

src/engine/sidechain/networkoutputstreamworker.cpp Outdated Show resolved Hide resolved
Comment on lines 38 to 39
mixxx::audio::SampleRate getDefaultSampleRate() const override {
return SoundDevice::kFallbackSampleRate;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have a naming issue with kFallbackSampleRate:

SoundManagerConfig::kFallbackSampleRate = mixxx::audio::SampleRate(48000);
constexpr mixxx::audio::SampleRate SoundDevice::kFallbackSampleRate = mixxx::audio::SampleRate(44100);

Than we have:
constexpr auto kDefaultSampleRate = mixxx::audio::SampleRate(44100);
And various definitions in global namespaces.

I think the term kFallbackSampleRate has been invented for the 48000 Hz that all soundcards likely support.
The 44100 is Mixxx's default sample rate that matches CD rips and is the most common sample rate when the decision has been made.

I suggest to use the term kFallbackSampleRate for 48000 Hz and kDefaultSampleRate for 44100 or maybe even better:
kMixxxDefaultSampleRate ..

Than you may check which additional constants can be removed.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I renamed it.

Than you may check which additional constants can be removed.

I don't see what this has to do with this PR to be honest. As you already mentioned yourself, this PR is quite big and I don't get why we keep expanding the scope of PRs even further. I think its totally fine to fix one thing without also fixing some only tangentially related other thing.

We know the actual sample rate from the `EngineParameters` object, so
there is no need to hardcode some constant.
Copy link
Member

@daschuer daschuer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One remaining issue. The rest looks and works good. Thank you.

Comment on lines 13 to 16
constexpr mixxx::audio::SampleRate SoundManagerConfig::kMixxxDefaultSampleRate =
mixxx::audio::SampleRate(44100);
constexpr mixxx::audio::SampleRate SoundManagerConfig::kFallbackSampleRate =
mixxx::audio::SampleRate(48000);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
constexpr mixxx::audio::SampleRate SoundManagerConfig::kMixxxDefaultSampleRate =
mixxx::audio::SampleRate(44100);
constexpr mixxx::audio::SampleRate SoundManagerConfig::kFallbackSampleRate =
mixxx::audio::SampleRate(48000);
const mixxx::audio::SampleRate SoundManagerConfig::kMixxxDefaultSampleRate =
mixxx::audio::SampleRate(44100);
const mixxx::audio::SampleRate SoundManagerConfig::kFallbackSampleRate =
mixxx::audio::SampleRate(48000);

This produces a linker error with ldd.
It should be anyway better to match the definition in the header.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

make both constexpr, move to header instead? Or would you consider that to leak implementation details?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

987fd3a ok?

…ader

This is supposed to fix `ldd` linker errors that may occur with the
previous code.

See mixxxdj#11904 (comment)
for details.
Copy link
Member

@daschuer daschuer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, Thank you

@daschuer daschuer merged commit e4f2e05 into mixxxdj:main Sep 8, 2023
@Swiftb0y
Copy link
Member

Swiftb0y commented Sep 8, 2023

Thank you

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development

Successfully merging this pull request may close these issues.

3 participants