-
Notifications
You must be signed in to change notification settings - Fork 522
make ChannelMappingAudioProcessor, TrimmingAudioProcessor and ToFloatPcmAudioProcessor public UnstableApi instead of package-private #2339
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
Comments
As a side note, please could you share some information about what prevents delegating to a |
Hi @andrewlewis, I'm currently working on two different projects, somewhat related:
|
We are still working on #1931 and #415 (despite the silence on these issues), so hopefully this need to fork the class will go away.
Thanks for wanting to contribute the changes back to the library! When you get to this point, before spending too much time preparing pull requests for this, it would be great if you could outline the implementation idea in a new issue (or on the existing ones if applicable), just so we can make sure the design makes sense for the library. As an app, it's often easier to take shortcuts or rely on side channels to communicate preferences and properties, but when integrating it for everyone, it often ends up requiring more changes than you may anticipate. And maybe we get around to submit the pending drafts for both integrations ourselves until then :)
Don't see why they have to be package-private. I will send a change to make them public, so they can be easily reused in other contexts as well. |
ChannelMappingAudioProcessor, TrimmingAudioProcessor and ToFloatPcmAudioProcessor are currently package-private even though they might be useful in custom audio processing chains or custom version of audio sinks. Issue: #2339 PiperOrigin-RevId: 747857815
Thanks @tonihei! I'll make sure to consider writing an outline first (depending on how much time preparing the PR needs). One more question, considering the fast issue response times (which btw is very, very appreciated): are the PRs I submitted (the oldest one being 5 weeks old) not recieving feedback due to time constraints (in which case I totally understand that), did they fall off the radar or am I just too impatient? ;) |
Oh, and could |
We can move it to a shared util (like |
This makes it more easily reusable. Issue: #2339 PiperOrigin-RevId: 748713531
Thanks @tonihei :) closing this issue as resolved |
[REQUIRED] Use case description
I'm working on my own audio sink and started out by copy-pasting DefaultAudioSink into my project. After cleaning up some low-hanging fruits, I got quite a few errors because my sink can't access TrimmingAudioProcessor, ChannelMappingAudioProcessor and ToFloatPcmAudioProcessor; as they are package-private in another package. (I also got errors about AudioTrackPositionTracker and AudioDeviceInfoApi23, but those feel more like implementation details so no need to make them public.)
Proposed solution
Mark these classes as public
@UnstableApi
instead of package-privateAlternatives considered
I could of course copy paste them as well, but those are sufficiently abstracted and I'd never end up editing them, so that'd be suboptimal tbh.
The text was updated successfully, but these errors were encountered: