I don't know iOS that well, but on Android, does the NDK actually give us access to the MediaPlayer API? What do C++ NDK apps do?

I'd still like to know what the (platform-agnostic) API will look like, and I think that choosing to implement that Go API on e.g. MediaPlayer instead of OpenAL is putting the cart before the horse. You say that Player will have no significant API breaking changes. IIUC, that means it will continue to take a ReadSeekCloser, which means that you can't stream audio over a network (because you can't seek into a network connection). Is that a deliberate design decision? Will I be able to play a sine wave modulated on-the-fly by Go code? If so, what's the concurrency model? It's still unclear to me what's exactly in and out of scope of the audio API.

I think I've said this before, but I still think the first step is to get rough consensus on the big-picture API design. I'm wary of a significant implementation change like this that doesn't actually break API, because I think that the API needs to change in the long run, so we should design the API first.

I think I've said this before, but I still think the first step is to get rough consensus on the big-picture API design.

This is my feeling too. This seems too specific, and I have no way of evaluating whether it's a good idea without a picture of the greater context.

I agree with Nigel and Andrew. This is describing an implementation, but the first step is a design. That includes: a high-level description of what will be possible with the API, a survey of existing audio APIs on other platforms, a list of real-world programs that could be implemented with the features described in the API, and some example programs showing how programs can do those things with the new API.

Without specific use-cases selected and prototyped, an API will end up either too general (a common complaint among people I have asked for their opinion on audio APIs) or too limited (like the current audio package).

Personally, I'd prefer to see bindings to libstagefright for access to hardware decoding where possible.

In my experience, streaming synthesized audio via openal has not been overly problematic, aside from achieving sub-6ms software latency due to a delay in openal reporting buffers as processed; but, this only required a more adaptive buffering solution.

This is describing an implementation, but the first step is a design.

Could you extend what could be the expectation from an audio player that runs on mobile devices? I have no desire to design a generic audio framework that addresses each expectation for every possible common use case.

Without any actionable feedback, our conversations about the audio player is being constantly black-holed and I cannot progress on this issue.

I have a limited scope which is providing a player (plays, stops, pauses, etc) an audio source and does it effectively. If you desire to ship a framework that enables audio programmers, that's not in the scope of audio.Player and can be addressed later.

This is a proposal against audio.Player, not a proposal to replace the audio package. Please give feedback in the scope of my current improvement plan.

/cc @hyangah, who is missing from the CC list.

(a common complaint among people I have asked for their opinion on audio APIs) or too limited (like the current audio package).

An audio stack is consistent of several layers:

• HAL (+ drivers)
• Sequencing services, clocks, sync
• Audio stream services (+ codecs)
• Higher level audio programming APIs
• Highest level audio players

People will complain as long as you don't provide a viable solution for each layer. The question is whose complaint matters most to us at this point. The players will keep on living in exp, if we ever introduce low-level APIs that introduces reusable constructs such as core interfaces, we can always apply them to the players.

As we have discussed before: there are features we know we want the audio package to have that it does not. Streaming support is a good concrete example from Nigel, but we don't have a comprehensive analysis of what features we want and don't want yet. To do so involves doing some research and design work.

Part of that work would be answering questions like: of the top (say) 100 apps on each platform, how many can be built today with x/exp/audio? Can the ones that we cannot build be broken down into various categories? What features does each category need? Which of those features can be implemented in a portable way? How do other APIs implement these features?

(In retrospect this design work should have been done up front before any programming, but I did not yet have a good sense for how to think about portable mobile APIs.)

Until that's done, I can't judge whether a proposal about implementation details is a step forward or not.

I am reverting this proposal for the sake of a more comprehensive audio library proposal I am going to file soon. According to the feedback on this thread, we don't need an intermediate hotfix solution to improve the current state of things.