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

Added support for new "category" constraint for audio #664

Closed
wants to merge 1 commit into from

Conversation

sjdallst
Copy link

@alvestrand
Copy link
Contributor

This needs to explain how it relates to the content-hint extension; possibly it could be a PR on that specification instead if functionality there is missing.

@sjdallst
Copy link
Author

This needs to explain how it relates to the content-hint extension; possibly it could be a PR on that specification instead if functionality there is missing.

I'm wondering if there is a world where the solution I'm looking for is a combination of both of these specs. For example, would it be consistent and clear with both specifications if I:

  1. Changed the name of the constraint to something like "platformOptimization" (open to suggestions there).
  2. Updated the content-hint spec with new hints such as "speech-Recognition", "speech-Communication", "raw", and then add default behaviors corresponding to these new constraints (ex: "raw" as a content-hint would apply {platformOptimization: "raw"} as a default).

This would follow current patterns, and help show that these new constraints are functionally like other constraints. Functionally alike, as in, they result in new, audible differences if supported by the platform, and can be mixed and matched with other constraints.

@alvestrand
Copy link
Contributor

The preferred approach is to open a bug explaining what problem you intend to solve, and link to that in the PR description. Then we can keep the discussion of "how can this problem be solved" and the discussion of "is this solution well specified" separate.

I still haven't figured out precisely what the processing you desire is; for instance, the term "the exact stream that the user's device provides" isn't a well defined term, given that many/most user devices can be opened in multiple modes, where what is being provided is different for each mode. Existing constraints were defined exactly to influence the mode in which the device is opened.

@aboba
Copy link
Contributor

aboba commented Feb 28, 2020

@sjdallst I have filed an Issue corresponding to this PR:
#671

Can you help fill (by referring to various specifications) what needs to be done to meet the requirements?

@aboba
Copy link
Contributor

aboba commented Apr 2, 2020

I believe that this PR will be reformulated as PR to content-hints.

@sjdallst
Copy link
Author

sjdallst commented Apr 2, 2020

Yes, closing this PR as it is moving to content-hints. Will follow up with a link to the new PR.

@sjdallst sjdallst closed this Apr 2, 2020
@sjdallst sjdallst deleted the user/sjdallst/audioCategory branch April 2, 2020 17:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants