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

New mixer API #760

Merged
merged 41 commits into from
Jul 16, 2014
Merged

New mixer API #760

merged 41 commits into from
Jul 16, 2014

Conversation

jodal
Copy link
Member

@jodal jodal commented Jun 22, 2014

For you interested. Still work in progress. Do not merge.

Addresses #665.

@jodal jodal added this to the v0.20 - Audio and mixer cleanup milestone Jun 22, 2014
@jodal jodal removed the Core label Jun 22, 2014
@adamcik
Copy link
Member

adamcik commented Jun 23, 2014

Should be consider adding a gst mixer and a auto gst mixer perhaps?

@jodal
Copy link
Member Author

jodal commented Jun 23, 2014

If we pass not just config but also audio to the mixer's __init__(), we can have a bundled SoftwareMixer that use mopidy.audio to change the software volume in GStreamer's pipeline. That way, software mixing and hardware mixing will be the exact same thing from the perspective of the core layer.

Adding other GStreamer mixers feels short sighted as they're going way soon anyway.

@adamcik
Copy link
Member

adamcik commented Jun 23, 2014

Since we have the code for the gst mixers it just seems trivial to wrap it. Wouldn't need to even be the auto one, just the pare from gst-launch and extract a mixer parts. Gives a simple transition plan as the mixer switch we can get in fast, a switch to 1.x will be more bumpy I'm sure.

@jodal
Copy link
Member Author

jodal commented Jun 23, 2014

I'm hoping that the software mixer will be the safe and useful haven for users while transitioning.

@jodal
Copy link
Member Author

jodal commented Jul 7, 2014

I think this is ready for review.

Not that Mopidy's develop branch is ready to get this merged, as we haven't released 0.19.0 yet.

@jodal
Copy link
Member Author

jodal commented Jul 12, 2014

From alsamixer manpage:

In alsamixer, the volume is mapped to a value that is more natural for
a human ear. The mapping is designed so that the position in the
interval is proportional to the volume as a human ear would perceive
it, i.e. the position is the cubic root of the linear sample multipli‐
cation factor. For controls with a small range (24 dB or less), the
mapping is linear in the dB values so that each step has the same size
visually.

Only for controls without dB information, a linear mapping of the hard‐
ware volume register values is used (this is the same algorithm as used
in the old alsamixer).

amixer can expose both values, using -R and -M arguments.

alsamixer implementation of "raw" linear scale to "natural" logaritmic dB scale: http://git.alsa-project.org/?p=alsa-utils.git;a=blob;f=alsamixer/volume_mapping.c;h=1c0d7c45e6686239464e1b0bbc8983ea57f3914f;hb=HEAD

logger.debug('Mixer event: mute_changed(mute=%s)', mute)
MixerListener.send('mute_changed', mute=mute)

def trigger_events_for_any_changes(self):
Copy link
Member

Choose a reason for hiding this comment

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

To me this feels like it doesn't belong in a base class with a minimal API. This could either be moved to core, though that would be a bit more back and forth. Or we could have a state tracker helper which implementations could use to get this behavior.

Copy link
Member Author

Choose a reason for hiding this comment

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

Moving it to core doesn't help mixers with emitting mixer events, as they don't know anything about core.

A state tracker helper sounds like something to consider if/when we revamp the event system, like we've been talking about.

Copy link
Member

Choose a reason for hiding this comment

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

Sorry, forgot to add that I'm assuming that the event gets changed to something changed for that case.

@adamcik
Copy link
Member

adamcik commented Jul 14, 2014

That should be it for this time round.

end result should be the same without any changes to this config value.

- Deprecated the :confval:`audio/mixer_track` config value. This config value
is no longer in use. Mixer extensions that needs additional configuration
Copy link
Member

Choose a reason for hiding this comment

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

s/needs/need/


def set_mute(self, mute):
"""
Mute or unmute of the installed mixer.
Mute or unmute of the software mixer.

:param mute: Wether to mute the mixer or not.
Copy link
Member

Choose a reason for hiding this comment

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

/wether/whether/ (while we're here). Fun fact: a 'wether' is a castrated ram!

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 looked that word up in dictionary just yesterday!

Copy link
Member Author

Choose a reason for hiding this comment

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

That is, "whether", not "castrated ram" :P

@@ -24,7 +24,7 @@

_audio_schema = ConfigSchema('audio')
_audio_schema['mixer'] = String()
_audio_schema['mixer_track'] = String(optional=True)
_audio_schema['mixer_track'] = Deprecated()
Copy link
Member

Choose a reason for hiding this comment

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

Maybe this is another PR... but s/Deprecated/Depreciated/

Copy link
Contributor

Choose a reason for hiding this comment

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

You must be mistaken on this one - "diminish in value over a period of time."
Whereas "deprecated" is something that is no longer used or will soon be out of use.

Good catches on the other ones, though.

Copy link
Member

Choose a reason for hiding this comment

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

And I always thought it was the other one, how embarrassing!

Copy link
Contributor

Choose a reason for hiding this comment

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

It doesn't matter wether or not you knew, together we can fix anything ;-)

@adamcik
Copy link
Member

adamcik commented Jul 14, 2014

I'm still not sold on adding the any value changed helper as part of the API. Other than that this looks good to go.

@jodal jodal modified the milestones: v0.19 - MPD engine rewrite and new web server, v0.20 - Audio cleanup Jul 14, 2014
@jodal
Copy link
Member Author

jodal commented Jul 14, 2014

I think my only problem with that method is the name. What about something like trigger_events_for_changed_values?

@jodal
Copy link
Member Author

jodal commented Jul 15, 2014

I renamed it and moved it into the software helper, so it's no longer part of the public mixer API.

adamcik added a commit that referenced this pull request Jul 16, 2014
@adamcik adamcik merged commit c6d810a into mopidy:develop Jul 16, 2014
@jodal jodal deleted the feature/mixers branch July 16, 2014 20:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-audio Area: Audio layer
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants