语言

Menu
Sites
Language
What is the device-preferred PCM format for the Samsung Gear S3 smartwatch?

Hi!

The audio guide found at https://developer.tizen.org/development/guides/native-application/media-and-camera/raw-audio-playback-and-recording recommends that the app choses the device-preferred PCM format for audio output. What is the device-preferred format for the Samsung Gear S3 smartwatch? Is it 8 or 16 bit? Is it mono or stereo? And what about sample rate? 41000 Hz, 48000 Hz or something else?

Best regards, Stian

编辑者为: Stian Andre Olsen 开 11 3月, 2018
列表

响应

2 回复
Armaan-Ul- Islam

I've also seen the suggestion on "Raw Audio Playback and Recording Guide" to Use "device-preferred PCM format":

  • To reduce the processing overhead inside, use the target device-preferred PCM format (for example, signed 16-bit little endian, stereo, 44100 Hz).
  • Using the preferred format reduces internal operations, such as converting audio samples from mono to stereo or re-sampling audio frequency to fit the target device's input sample rate.

 

But I haven't found any API to retrieve device-preferred PCM format yet.

One way could be "Trial & Error" process, tune the parameters to reach optimum runtime. As the guides mentioned, a wild guess would be "signed 16-bit little endian, stereo, 44100 Hz".

Stian Andre Olsen

Thanks!

I have the same "wild guess" ;-). After all, that's what the documentation mentiones. However, as far as I know the watch have only one speaker, hence it seems reasonable that the watch has hardware optimized for mono sound. On the other hand, most audio files probably contains stereo. For now, I am using 16-bit, stereo, 44100 Hz.

I have also tried unsigned 8-bit mono sound and it plays ok. The only snag is that my silent bytes in the middle of the range (that is bytes containing 127), produces a short click when the sound is turned on or off. The odd thing is that the watch and emulator uses two different algorithms. The watch produces a click when I am using bytes = 127 but is is silent if I send bytes = 0. The emulator is exactly opposite. With signed 16-bit, this is not a problem.

Best regards, Stian