Improving data types.

[slimsag]

Something that struck me just recently is that if another package defines a function like this:

// Returns unsigned PCM 8-bit audio samples.
func getSamples() []uint8 {
}

We can't directly convert []uint8 to audio.PCM8Samples because it is defined as type PCM8Samples []PCM8 instead of type PCM8Samples []uint8. This is in fact different from the image package which doesn't do this sort of custom type definition for individual pixels.

I think it would make sense to remove the PCM8 type and instead directly use uint8 (this goes for other types like PCM16, F64, ALaw etc).

[slimsag]

If others agree, it would make sense to rename PCM8Samples and friends to just PCM8 too.

[slimsag]

In fact, F32 and F64 types are PCM encoded even though the type doesn't say it (like PCM8 types do). I propose the following renaming:

Old type	New type
type ALawSamples []ALaw	type ALaw []uint8
type MuLawSamples []MuLaw	type MuLaw []uint8
type PCM8Samples []PCM8	type Uint8 []uint8
type PCM16Samples []PCM16	type Int16 []int16
type PCM32Samples []PCM32	type Int32 []int32
type F32Samples []F32	type Float32 []float32
type F64Samples []F64	type Float64 []float64

This opens up the package to support new PCM encoded types like uint16 if needed in the future as well.

[mdlayher]

👍, looks good to me!

[mewmew]

I agree, this is definitely a step in the right direction as it simplifies the API and makes integration with independent backends easier. And, I also like that this brings it closer to the behaviour of the image package.