Re: [PATCH v4 4/6] core: add API header and driver header files

Re: [PATCH v4 4/6] core: add API header and driver header files

[Nallasellan, Singaravelan]

> +struct snd_compr_runtime {
> +	snd_pcm_state_t state;
> +	struct snd_compr_ops *ops;
> +	void *buffer;
Can we define buffer as char *?
> +	size_t buffer_size;
> +	size_t fragment_size;
Can we define buffer_size and fragment_size as unsigned items? 
Can we have negative size here?

> +	unsigned int fragments;
> +	size_t hw_pointer;
> +	size_t app_pointer;
> +	size_t bytes_written;
> +	size_t bytes_copied;
> +	wait_queue_head_t sleep;
> +};
> +

Re: [PATCH v4 4/6] core: add API header and driver header files

[Mark Brown]

On Tue, Dec 13, 2011 at 06:19:49PM +0530, Nallasellan, Singaravelan wrote:
> > +struct snd_compr_runtime {
> > +	snd_pcm_state_t state;
> > +	struct snd_compr_ops *ops;
> > +	void *buffer;

> Can we define buffer as char *?

Clearly we *can* but why would we want to do that for a pointer to
unstructured data?

> > +	size_t buffer_size;
> > +	size_t fragment_size;

> Can we define buffer_size and fragment_size as unsigned items? 
> Can we have negative size here?

Again, what is the advantage in doing this?

Re: [PATCH v4 4/6] core: add API header and driver header files

[Nallasellan, Singaravelan]

> > > +struct snd_compr_runtime {
> > > +	snd_pcm_state_t state;
> > > +	struct snd_compr_ops *ops;
> > > +	void *buffer;
> 
> > Can we define buffer as char *?
> 
> Clearly we *can* but why would we want to do that for a pointer to unstructured
> data?
True, it will always be pointer to bytes. u8 could also be used. 
No big advantage here. It will be clear.
> 
> > > +	size_t buffer_size;
> > > +	size_t fragment_size;
> 
> > Can we define buffer_size and fragment_size as unsigned items?
> > Can we have negative size here?
> 
> Again, what is the advantage in doing this?

The size will be positive anyways. Why don't we do it?
No big advantage here as well. It will be clear.

Re: [PATCH v4 4/6] core: add API header and driver header files

[Takashi Iwai]

At Tue, 13 Dec 2011 18:19:49 +0530,
Nallasellan, Singaravelan wrote:
> 
> > +	size_t buffer_size;
> > +	size_t fragment_size;
> Can we define buffer_size and fragment_size as unsigned items? 

size_t is unsigned.

But, it needs consideration whether size_t is the best choice, since
size_t is basically a long, thus its size is different between 32bit
and 64bit architectures.  This may lead to mess in many cases when you
think of overlapping.


Takashi

Re: [PATCH v4 4/6] core: add API header and driver header files

[Nallasellan, Singaravelan]

> > > +	size_t buffer_size;
> > > +	size_t fragment_size;
> > Can we define buffer_size and fragment_size as unsigned items?
> 
> size_t is unsigned.
> 
> But, it needs consideration whether size_t is the best choice, since size_t is basically
> a long, thus its size is different between 32bit and 64bit architectures.  This may lead
> to mess in many cases when you think of overlapping.
> 
Sorry for my mess on size_t.
I think the assumption here is 32 bits. Should u32 be fine here?

Re: [PATCH v4 4/6] core: add API header and driver header files

[Takashi Iwai]

At Tue, 13 Dec 2011 19:21:30 +0530,
Nallasellan, Singaravelan wrote:
> 
> > > > +	size_t buffer_size;
> > > > +	size_t fragment_size;
> > > Can we define buffer_size and fragment_size as unsigned items?
> > 
> > size_t is unsigned.
> > 
> > But, it needs consideration whether size_t is the best choice, since size_t is basically
> > a long, thus its size is different between 32bit and 64bit architectures.  This may lead
> > to mess in many cases when you think of overlapping.
> > 
> Sorry for my mess on size_t.
> I think the assumption here is 32 bits. Should u32 be fine here?

This depends pretty much on the demand and the implementation.
Unless a buffer over 4GB is needed, u32 should be OK for buffer_size,
etc.  (Or, in this case, unsigned int would be fine, too.  It's not
necessarily be limited to 32bit.  u32 or such is used usually for the
type that must be 32bit.)

But, the questions remain for hw_pointer, app_pointer, bytes_*
fields.  Are these supposed to be 32bit or more?  This question is
more important than the buffer size.  The buffer size would be rarely
over 32bit.  But, if hw_pointer or such represents the accumulated
position like ALSA PCM does, you'll face the overlapping problem.
32bit limit can be reached easily in the real use case.

When this changes between 32bit and 64bit, think twice about the 32bit
compat-layer on 64bit arch (and the corresponding user-space
implementation)...


Takashi

Re: [PATCH v4 4/6] core: add API header and driver header files

[Vinod Koul]

On Tue, 2011-12-13 at 15:04 +0100, Takashi Iwai wrote:
> At Tue, 13 Dec 2011 19:21:30 +0530,
> Nallasellan, Singaravelan wrote:
> > 
> > > > > +	size_t buffer_size;
> > > > > +	size_t fragment_size;
> > > > Can we define buffer_size and fragment_size as unsigned items?
> > > 
> > > size_t is unsigned.
> > > 
> > > But, it needs consideration whether size_t is the best choice, since size_t is basically
> > > a long, thus its size is different between 32bit and 64bit architectures.  This may lead
> > > to mess in many cases when you think of overlapping.
> > > 
> > Sorry for my mess on size_t.
> > I think the assumption here is 32 bits. Should u32 be fine here?
> 
> This depends pretty much on the demand and the implementation.
> Unless a buffer over 4GB is needed, u32 should be OK for buffer_size,
> etc.  (Or, in this case, unsigned int would be fine, too.  It's not
> necessarily be limited to 32bit.  u32 or such is used usually for the
> type that must be 32bit.)
I don't think someone would need buffer of 4GB :)

> But, the questions remain for hw_pointer, app_pointer, bytes_*
> fields.  Are these supposed to be 32bit or more?  This question is
> more important than the buffer size.  The buffer size would be rarely
> over 32bit.  But, if hw_pointer or such represents the accumulated
> position like ALSA PCM does, you'll face the overlapping problem.
> 32bit limit can be reached easily in the real use case.
the pointer are offsets within the ring buffer.
there are cumulative counters which will get overlapped after the
size_t/u32 value.
> 
> When this changes between 32bit and 64bit, think twice about the 32bit
> compat-layer on 64bit arch (and the corresponding user-space
> implementation)...
Is it a fair assumption that userspace compiled for 32 bit should work
with 32 bit kernel and same for 64 bit, or does the ABI mandate it be
consistent across 32 and 64 bits. In the latter case we should change
the ones in kernel ABI to consistent size of u32/u64. IMO u32 should be
fine, please let me know if anyone thinks otherwise.
In former size_t should be fine :)

-- 
~Vinod

Re: [PATCH v4 4/6] core: add API header and driver header files

[Takashi Iwai]

At Tue, 13 Dec 2011 19:54:27 +0530,
Vinod Koul wrote:
> 
> On Tue, 2011-12-13 at 15:04 +0100, Takashi Iwai wrote:
> > At Tue, 13 Dec 2011 19:21:30 +0530,
> > Nallasellan, Singaravelan wrote:
> > > 
> > > > > > +	size_t buffer_size;
> > > > > > +	size_t fragment_size;
> > > > > Can we define buffer_size and fragment_size as unsigned items?
> > > > 
> > > > size_t is unsigned.
> > > > 
> > > > But, it needs consideration whether size_t is the best choice, since size_t is basically
> > > > a long, thus its size is different between 32bit and 64bit architectures.  This may lead
> > > > to mess in many cases when you think of overlapping.
> > > > 
> > > Sorry for my mess on size_t.
> > > I think the assumption here is 32 bits. Should u32 be fine here?
> > 
> > This depends pretty much on the demand and the implementation.
> > Unless a buffer over 4GB is needed, u32 should be OK for buffer_size,
> > etc.  (Or, in this case, unsigned int would be fine, too.  It's not
> > necessarily be limited to 32bit.  u32 or such is used usually for the
> > type that must be 32bit.)
> I don't think someone would need buffer of 4GB :)
> 
> > But, the questions remain for hw_pointer, app_pointer, bytes_*
> > fields.  Are these supposed to be 32bit or more?  This question is
> > more important than the buffer size.  The buffer size would be rarely
> > over 32bit.  But, if hw_pointer or such represents the accumulated
> > position like ALSA PCM does, you'll face the overlapping problem.
> > 32bit limit can be reached easily in the real use case.
> the pointer are offsets within the ring buffer.

OK, then it's no problem to assume 32bit is enough.

> there are cumulative counters which will get overlapped after the
> size_t/u32 value.

Which field specifically?  The cumulative counter has been a problem.

> > When this changes between 32bit and 64bit, think twice about the 32bit
> > compat-layer on 64bit arch (and the corresponding user-space
> > implementation)...
> Is it a fair assumption that userspace compiled for 32 bit should work
> with 32 bit kernel and same for 64 bit, or does the ABI mandate it be
> consistent across 32 and 64 bits.

The 32bit user-space must work with 64bit kernel.  It means, it'd be
much easier if ABI definition is compatible between 32 and 64bit.

That is, using a long type in the ABI definition should be definitely
avoided.  We had long fields in ALSA PCM field definitions, and this
caused lots of really nasty problems.  So, I tell you -- don't do it
again.  Learn from the history :)

Of course, this is about the ABI definition.  But, the internal
structure (types, etc) usually follows the ABI requirement.  So I
stated the questions here.

> In the latter case we should change
> the ones in kernel ABI to consistent size of u32/u64. IMO u32 should be
> fine, please let me know if anyone thinks otherwise.
> In former size_t should be fine :)


thanks,

Takashi

Re: [PATCH v4 4/6] core: add API header and driver header files

[Vinod Koul]

On Tue, 2011-12-13 at 16:01 +0100, Takashi Iwai wrote:
> At Tue, 13 Dec 2011 19:54:27 +0530,
> Vinod Koul wrote:
> > 
> > On Tue, 2011-12-13 at 15:04 +0100, Takashi Iwai wrote:
> > > At Tue, 13 Dec 2011 19:21:30 +0530,
> > > Nallasellan, Singaravelan wrote:
> > > > 
> > > > > > > +	size_t buffer_size;
> > > > > > > +	size_t fragment_size;
> > > > > > Can we define buffer_size and fragment_size as unsigned items?
> > > > > 
> > > > > size_t is unsigned.
> > > > > 
> > > > > But, it needs consideration whether size_t is the best choice, since size_t is basically
> > > > > a long, thus its size is different between 32bit and 64bit architectures.  This may lead
> > > > > to mess in many cases when you think of overlapping.
> > > > > 
> > > > Sorry for my mess on size_t.
> > > > I think the assumption here is 32 bits. Should u32 be fine here?
> > > 
> > > This depends pretty much on the demand and the implementation.
> > > Unless a buffer over 4GB is needed, u32 should be OK for buffer_size,
> > > etc.  (Or, in this case, unsigned int would be fine, too.  It's not
> > > necessarily be limited to 32bit.  u32 or such is used usually for the
> > > type that must be 32bit.)
> > I don't think someone would need buffer of 4GB :)
> > 
> > > But, the questions remain for hw_pointer, app_pointer, bytes_*
> > > fields.  Are these supposed to be 32bit or more?  This question is
> > > more important than the buffer size.  The buffer size would be rarely
> > > over 32bit.  But, if hw_pointer or such represents the accumulated
> > > position like ALSA PCM does, you'll face the overlapping problem.
> > > 32bit limit can be reached easily in the real use case.
> > the pointer are offsets within the ring buffer.
> 
> OK, then it's no problem to assume 32bit is enough.
Great :)
> 
> > there are cumulative counters which will get overlapped after the
> > size_t/u32 value.
> 
> Which field specifically?  The cumulative counter has been a problem.
There are two fields in snd_compr_runtime, bytes_written and
bytes_copied. Both are counting cumulative bytes written to ring buffer
and bytes copied by DSP.
Assumption is that they will wrap once they reach max. That should not
cause issue in core.
Then the core will wrap around the timestamp value. My thought was user
lib should always take care of kernel wrapping and provide sufficiently
large tstamp value to application.
> 
> > > When this changes between 32bit and 64bit, think twice about the 32bit
> > > compat-layer on 64bit arch (and the corresponding user-space
> > > implementation)...
> > Is it a fair assumption that userspace compiled for 32 bit should work
> > with 32 bit kernel and same for 64 bit, or does the ABI mandate it be
> > consistent across 32 and 64 bits.
> 
> The 32bit user-space must work with 64bit kernel.  It means, it'd be
> much easier if ABI definition is compatible between 32 and 64bit.
> 
> That is, using a long type in the ABI definition should be definitely
> avoided.  We had long fields in ALSA PCM field definitions, and this
> caused lots of really nasty problems.  So, I tell you -- don't do it
> again.  Learn from the history :)
> 
> Of course, this is about the ABI definition.  But, the internal
> structure (types, etc) usually follows the ABI requirement.  So I
> stated the questions here.
Right. I think we should be pretty decent if we just change the kernel
APIs to u32. Based on that all other non cumulative counter should be
u32 and cumulative ones u64 :)
That was we will not care what bit userland is, and otherthings will
work as expected.

Thanks
-- 
~Vinod

[PATCH v3 0/6] core: add compress data API to ALSA kernel

[Vinod Koul]

As agreed during the ASoC workshop in May 2011, this set of patches are a
proposal from Intel to add a new compressed data interface to ALSA. This
proposal builds on the existing Intel solution and the experience gathered over
two years with Meego and Android solutions. This proposal is no longer
Intel-specific and was generalized with the addition of a basic core;
codec-related definitions are based on the vendor-neutral OpenMAX AL standard. 

These patches are also available in git tree:
git://git.infradead.org/users/vkoul/snd-compress.git v3_patches

Changes in v3:
 Fixed the device registration for compressed devices as discussed
 moved card creation to lower level drivers
 Added new api for device node creation
 changes fragment/frame callbacks to single inlined callback

Changes in v2:
 Fixed the comments revived in v2
 Fixed the comments recieved during LPC discussions
 add support for alsa device registeration
 fix the bugs found in testing

Omair Mohammed Abdullah (1):
  core: add support for compressed devices

Pierre-Louis Bossart (1):
  compress API documentation

Vinod Koul (4):
  core: add compress parameter definations
  core: add API header and driver header files
  core: add support for compress_offload
  core: add makefile and kconfig file for compress

 Documentation/sound/alsa/snd_compress_data.txt |  184 +++++++
 include/sound/compress_driver.h                |  164 ++++++
 include/sound/compress_offload.h               |  151 +++++
 include/sound/core.h                           |    1 +
 include/sound/minors.h                         |    7 +-
 include/sound/snd_compress_params.h            |  395 +++++++++++++
 sound/core/Kconfig                             |    8 +
 sound/core/Makefile                            |    4 +
 sound/core/compress_offload.c                  |  701 ++++++++++++++++++++++++
 sound/core/sound.c                             |    6 +
 10 files changed, 1620 insertions(+), 1 deletions(-)
 create mode 100644 Documentation/sound/alsa/snd_compress_data.txt
 create mode 100644 include/sound/compress_driver.h
 create mode 100644 include/sound/compress_offload.h
 create mode 100644 include/sound/snd_compress_params.h
 create mode 100644 sound/core/compress_offload.c

[PATCH v4 4/6] core: add API header and driver header files

[Vinod Koul]

This patch adds the header files for ioctl definations and header file for
driver APIs for lower level device drivers to use

Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
---
 include/sound/compress_driver.h  |  166 ++++++++++++++++++++++++++++++++++++++
 include/sound/compress_offload.h |  151 ++++++++++++++++++++++++++++++++++
 2 files changed, 317 insertions(+), 0 deletions(-)
 create mode 100644 include/sound/compress_driver.h
 create mode 100644 include/sound/compress_offload.h

diff --git a/include/sound/compress_driver.h b/include/sound/compress_driver.h
new file mode 100644
index 0000000..1baa938
--- /dev/null
+++ b/include/sound/compress_driver.h
@@ -0,0 +1,166 @@
+/*
+ *  compress_driver.h - compress offload driver definations
+ *
+ *  Copyright (C) 2011 Intel Corporation
+ *  Authors:	Vinod Koul <vinod.koul@linux.intel.com>
+ *		Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
+ *  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; version 2 of the License.
+ *
+ *  This program is distributed in the hope that it will be useful, but
+ *  WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ *  General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License along
+ *  with this program; if not, write to the Free Software Foundation, Inc.,
+ *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ *
+ */
+#ifndef __COMPRESS_DRIVER_H
+#define __COMPRESS_DRIVER_H
+
+#include <linux/types.h>
+#include <linux/sched.h>
+#include <sound/compress_offload.h>
+#include <sound/asound.h>
+#include <sound/pcm.h>
+
+struct snd_compr_ops;
+
+/**
+ * struct snd_compr_runtime: runtime stream description
+ * @state: stream state
+ * @ops: pointer to DSP callbacks
+ * @buffer: pointer to kernel buffer, valid only when not in mmap mode or
+ *	DSP doesn't implement copy
+ * @buffer_size: size of the above buffer
+ * @fragment_size: size of buffer fragment in bytes
+ * @fragments: number of such fragments
+ * @hw_pointer: offset of last location in buffer where DSP copied data
+ * @app_pointer: offset of last location in buffer where app wrote data
+ * @bytes_written: cummilative bytes written to device
+ * @bytes_copied: cummilative bytes copied by DSP
+ * @sleep: poll sleep
+ */
+struct snd_compr_runtime {
+	snd_pcm_state_t state;
+	struct snd_compr_ops *ops;
+	void *buffer;
+	size_t buffer_size;
+	size_t fragment_size;
+	unsigned int fragments;
+	size_t hw_pointer;
+	size_t app_pointer;
+	size_t bytes_written;
+	size_t bytes_copied;
+	wait_queue_head_t sleep;
+};
+
+/**
+ * struct snd_compr_stream: compressed stream
+ * @name: device name
+ * @ops: pointer to DSP callbacks
+ * @runtime: pointer to runtime structure
+ * @device: device pointer
+ * @direction: stream direction, playback/recording
+ * @private_data: pointer to DSP private data
+ */
+struct snd_compr_stream {
+	const char *name;
+	struct snd_compr_ops *ops;
+	struct snd_compr_runtime *runtime;
+	struct snd_compr *device;
+	unsigned int direction;
+	void *private_data;
+};
+
+/**
+ * struct snd_compr_ops: compressed path DSP operations
+ * @open: Open the compressed stream
+ * This callback is mandatory and shall keep dsp ready to receive the stream
+ * parameter
+ * @free: Close the compressed stream, mandatory
+ * @set_params: Sets the compressed stream parameters, mandatory
+ * This can be called in during stream creation only to set codec params
+ * and the stream properties
+ * @get_params: retrieve the codec parameters, mandatory
+ * @trigger: Trigger operations like start, pause, resume, drain, stop.
+ * This callback is mandatory
+ * @pointer: Retrieve current h/w pointer information. Mandatory
+ * @copy: Copy the compressed data to/from userspace, Optional
+ * Can't be implemented if DSP supports mmap
+ * @mmap: DSP mmap method to mmap DSP memory
+ * @ack: Ack for DSP when data is written to audio buffer, Optional
+ * Not valid if copy is implemented
+ * @get_caps: Retrieve DSP capabilities, mandatory
+ * @get_codec_caps: Retrieve capabilities for a specific codec, mandatory
+ */
+struct snd_compr_ops {
+	int (*open)(struct snd_compr_stream *stream);
+	int (*free)(struct snd_compr_stream *stream);
+	int (*set_params)(struct snd_compr_stream *stream,
+			struct snd_compr_params *params);
+	int (*get_params)(struct snd_compr_stream *stream,
+			struct snd_codec *params);
+	int (*trigger)(struct snd_compr_stream *stream, int cmd);
+	int (*pointer)(struct snd_compr_stream *stream,
+			struct snd_compr_tstamp *tstamp);
+	int (*copy)(struct snd_compr_stream *stream, const char __user *buf,
+		       size_t count);
+	int (*mmap)(struct snd_compr_stream *stream,
+			struct vm_area_struct *vma);
+	int (*ack)(struct snd_compr_stream *stream, size_t bytes);
+	int (*get_caps) (struct snd_compr_stream *stream,
+			struct snd_compr_caps *caps);
+	int (*get_codec_caps) (struct snd_compr_stream *stream,
+			struct snd_compr_codec_caps *codec);
+};
+
+/**
+ * struct snd_compr: Compressed device
+ * @name: DSP device name
+ * @dev: Device pointer
+ * @ops: pointer to DSP callbacks
+ * @private_data: pointer to DSP pvt data
+ * @card: sound card pointer
+ * @direction: Playback or capture direction
+ * @lock: device lock
+ * @device: device id
+ */
+struct snd_compr {
+	const char *name;
+	struct device *dev;
+	struct snd_compr_ops *ops;
+	void *private_data;
+	struct snd_card *card;
+	unsigned int direction;
+	struct mutex lock;
+	int device;
+};
+
+/* compress device register APIs */
+int snd_compress_register(struct snd_compr *device);
+int snd_compress_deregister(struct snd_compr *device);
+int snd_compress_new(struct snd_card *card, int device,
+			int type, struct snd_compr *compr);
+
+/* dsp driver callback apis
+ * For playback: driver should call snd_compress_fragment_elapsed() to let the
+ * framework know that a fragment has been consumed from the ring buffer
+ *
+ * For recording: we want to know when a frame is available or when
+ * at least one frame is available so snd_compress_frame_elapsed()
+ * callback should be called when a encodeded frame is available
+ */
+static inline void snd_compr_fragment_elapsed(struct snd_compr_stream *stream)
+{
+	wake_up(&stream->runtime->sleep);
+}
+
+#endif
diff --git a/include/sound/compress_offload.h b/include/sound/compress_offload.h
new file mode 100644
index 0000000..2358c86
--- /dev/null
+++ b/include/sound/compress_offload.h
@@ -0,0 +1,151 @@
+/*
+ *  compress_offload.h - compress offload header definations
+ *
+ *  Copyright (C) 2011 Intel Corporation
+ *  Authors:	Vinod Koul <vinod.koul@linux.intel.com>
+ *		Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
+ *  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; version 2 of the License.
+ *
+ *  This program is distributed in the hope that it will be useful, but
+ *  WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ *  General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License along
+ *  with this program; if not, write to the Free Software Foundation, Inc.,
+ *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ *
+ */
+#ifndef __COMPRESS_OFFLOAD_H
+#define __COMPRESS_OFFLOAD_H
+
+#include <linux/types.h>
+#include <sound/asound.h>
+#include <sound/snd_compress_params.h>
+
+
+#define SNDRV_COMPRESS_VERSION SNDRV_PROTOCOL_VERSION(0, 1, 0)
+/**
+ * struct snd_compressed_buffer: compressed buffer
+ * @fragment_size: size of buffer fragment in bytes
+ * @fragments: number of such fragments
+ */
+struct snd_compressed_buffer {
+	size_t fragment_size;
+	int fragments;
+};
+
+/**
+ * struct snd_compr_params: compressed stream params
+ * @buffer: buffer description
+ * @codec: codec parameters
+ * @no_wake_mode: dont wake on fragment elapsed
+ */
+struct snd_compr_params {
+	struct snd_compressed_buffer buffer;
+	struct snd_codec codec;
+	bool no_wake_mode;
+};
+
+/**
+ * struct snd_compr_tstamp: timestamp descriptor
+ * @copied_bytes: Number of bytes offset in ring buffer to DSP
+ * @copied_total: Total number of bytes copied from/to ring buffer to/by DSP
+ * @frames: Frames decoded or encoded by DSP
+ * @rendered: Frames rendered or recieved by DSP into a mixer or an audio
+ * output/input
+ * @sampling_rate: sampling rate of audio
+ */
+struct snd_compr_tstamp {
+	size_t copied_bytes;
+	size_t copied_total;
+	size_t frames;
+	size_t rendered;
+	__u32 sampling_rate;
+};
+
+/**
+ * struct snd_compr_avail: avail descriptor
+ * @avail: Number of bytes available in ring buffer for writing/reading
+ * @tstamp: timestamp infomation
+ */
+struct snd_compr_avail {
+	size_t avail;
+	struct snd_compr_tstamp tstamp;
+};
+
+/**
+ * struct snd_compr_caps: caps descriptor
+ * @codecs: pointer to array of codecs
+ * @min_fragment_size: minimum fragment supported by DSP
+ * @max_fragment_size: maximum fragment supported by DSP
+ * @min_fragments: min fragments supported by DSP
+ * @max_fragments: max fragments supported by DSP
+ * @num_codecs: number of codecs supported
+ * @reserved: reserved field
+ */
+struct snd_compr_caps {
+	__u32 num_codecs;
+	__u32 min_fragment_size;
+	__u32 max_fragment_size;
+	__u32 min_fragments;
+	__u32 max_fragments;
+	__u32 codecs[MAX_NUM_CODECS];
+	__u32 reserved[11];
+};
+
+/**
+ * struct snd_compr_codec_caps: query capability of codec
+ * @codec: codec for which capability is queried
+ * @num_descriptors: number of codec descriptors
+ * @descriptor: array of codec capability descriptor
+ */
+struct snd_compr_codec_caps {
+	__u32 codec;
+	__u32 num_descriptors;
+	struct snd_codec_desc descriptor[MAX_NUM_CODEC_DESCRIPTORS];
+};
+
+/**
+ * compress path ioctl definitions
+ * SNDRV_COMPRESS_GET_CAPS: Query capability of DSP
+ * SNDRV_COMPRESS_GET_CODEC_CAPS: Query capability of a codec
+ * SNDRV_COMPRESS_SET_PARAMS: Set codec and stream parameters
+ * Note: only codec params can be changed runtime and stream params cant be
+ * SNDRV_COMPRESS_GET_PARAMS: Query codec params
+ * SNDRV_COMPRESS_TSTAMP: get the current timestamp value
+ * SNDRV_COMPRESS_AVAIL: get the current buffer avail value.
+ * This also queries the tstamp properties
+ * SNDRV_COMPRESS_PAUSE: Pause the running stream
+ * SNDRV_COMPRESS_RESUME: resume a paused stream
+ * SNDRV_COMPRESS_START: Start a stream
+ * SNDRV_COMPRESS_STOP: stop a running stream, discarding ring buffer content
+ * and the buffers currently with DSP
+ * SNDRV_COMPRESS_DRAIN: Play till end of buffers and stop after that
+ * SNDRV_COMPRESS_IOCTL_VERSION: Query the API version
+ */
+#define SNDRV_COMPRESS_IOCTL_VERSION	_IOR('C', 0x00, int)
+#define SNDRV_COMPRESS_GET_CAPS		_IOWR('C', 0x10, struct snd_compr_caps)
+#define SNDRV_COMPRESS_GET_CODEC_CAPS	_IOWR('C', 0x11, struct snd_compr_codec_caps)
+#define SNDRV_COMPRESS_SET_PARAMS	_IOW('C', 0x12, struct snd_compr_params)
+#define SNDRV_COMPRESS_GET_PARAMS	_IOR('C', 0x13, struct snd_codec)
+#define SNDRV_COMPRESS_TSTAMP		_IOR('C', 0x20, struct snd_compr_tstamp)
+#define SNDRV_COMPRESS_AVAIL		_IOR('C', 0x21, struct snd_compr_avail)
+#define SNDRV_COMPRESS_PAUSE		_IO('C', 0x30)
+#define SNDRV_COMPRESS_RESUME		_IO('C', 0x31)
+#define SNDRV_COMPRESS_START		_IO('C', 0x32)
+#define SNDRV_COMPRESS_STOP		_IO('C', 0x33)
+#define SNDRV_COMPRESS_DRAIN		_IO('C', 0x34)
+/*
+ * TODO
+ * 1. add mmap support
+ *
+ */
+#define SND_COMPR_TRIGGER_DRAIN 7 /*FIXME move this to pcm.h */
+#endif
-- 
1.7.0.4