[ALSA-UTILS][PATCH] Add support for cplay and crecord

[ALSA-UTILS][PATCH] Add support for cplay and crecord

[Qais Yousef]

cplay and crecord use compress offload API to play and record compressed audio.

They're based on cplay and crec from tinycompress library using LGPL license.

For now cplay only supports playing mp3 files.

Signed-off-by: Qais Yousef <qais.yousef@imgtec.com>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Mark Brown <broonie@kernel.org>
---
I renamed crec to crecord also to match aplay and arecord, hopefully
you don't mind Vinod.

This patch is dependent on my other patch that adds support for compress offload
to alsa-lib.

I needed to include <sound/compress_params.h> in cplay.c and crec.c
but I couldn't find an example of any C file which directly includes <sound/*.h>
The norm seems to be to just include <alsa/asoundlib.h>. Do I need to
redefine structs from <sound/compress_params.h> to newly added <alsa/compress.h>?
<alsa/pcm.h> seems to redefine structs from <sound/asound.h>.

I could only test cplay but have no means to test crecord at the moment.

 Makefile.am       |   3 +
 configure.ac      |   6 +-
 cplay/Makefile.am |  14 ++
 cplay/cplay.c     | 294 +++++++++++++++++++++++++++++++++++
 cplay/crec.c      | 449 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 cplay/tinymp3.h   |  72 +++++++++
 6 files changed, 837 insertions(+), 1 deletion(-)
 create mode 100644 cplay/Makefile.am
 create mode 100644 cplay/cplay.c
 create mode 100644 cplay/crec.c
 create mode 100644 cplay/tinymp3.h

diff --git a/Makefile.am b/Makefile.am
index 5bbe588a8d84..0842657530fd 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -19,6 +19,9 @@ if ALSALOOP
 SUBDIRS += alsaloop
 endif
 endif
+if HAVE_COMPRESS
+SUBDIRS += cplay
+endif
 if HAVE_SEQ
 SUBDIRS += seq
 endif
diff --git a/configure.ac b/configure.ac
index f09aa5484d1d..c08c24b90658 100644
--- a/configure.ac
+++ b/configure.ac
@@ -42,6 +42,8 @@ fi
 dnl Check components
 AC_CHECK_HEADERS([alsa/pcm.h], [have_pcm="yes"], [have_pcm="no"],
   [#include <alsa/asoundlib.h>])
+AC_CHECK_HEADERS([alsa/compress.h], [have_compress="yes"], [have_compress="no"],
+  [#include <alsa/asoundlib.h>])
 AC_CHECK_HEADERS([alsa/mixer.h], [have_mixer="yes"], [have_mixer="no"],
   [#include <alsa/asoundlib.h>])
 AC_CHECK_HEADERS([alsa/rawmidi.h], [have_rawmidi="yes"], [have_rawmidi="no"],
@@ -54,6 +56,7 @@ AC_CHECK_HEADERS([samplerate.h], [have_samplerate="yes"], [have_samplerate="no"]
   [#include <samplerate.h>])
 
 AM_CONDITIONAL(HAVE_PCM, test "$have_pcm" = "yes")
+AM_CONDITIONAL(HAVE_COMPRESS, test "$have_compress" = "yes")
 AM_CONDITIONAL(HAVE_MIXER, test "$have_mixer" = "yes")
 AM_CONDITIONAL(HAVE_RAWMIDI, test "$have_rawmidi" = "yes")
 AM_CONDITIONAL(HAVE_SEQ, test "$have_seq" = "yes")
@@ -359,7 +362,8 @@ AC_OUTPUT(Makefile alsactl/Makefile alsactl/init/Makefile \
 	  alsaconf/alsaconf alsaconf/Makefile \
 	  alsaconf/po/Makefile \
 	  alsaucm/Makefile \
-	  aplay/Makefile include/Makefile iecset/Makefile utils/Makefile \
+	  aplay/Makefile cplay/Makefile \
+	  include/Makefile iecset/Makefile utils/Makefile \
 	  utils/alsa-utils.spec seq/Makefile seq/aconnect/Makefile \
 	  seq/aplaymidi/Makefile seq/aseqdump/Makefile seq/aseqnet/Makefile \
 	  speaker-test/Makefile speaker-test/samples/Makefile \
diff --git a/cplay/Makefile.am b/cplay/Makefile.am
new file mode 100644
index 000000000000..bcb1bfce7a2d
--- /dev/null
+++ b/cplay/Makefile.am
@@ -0,0 +1,14 @@
+LIBRT = @LIBRT@
+
+AM_CPPFLAGS = -I$(top_srcdir)/include
+LDADD = $(LIBINTL) $(LIBRT)
+
+# debug flags
+#LDFLAGS = -static
+#LDADD += -ldl
+
+bin_PROGRAMS = cplay crecord
+noinst_HEADERS = tinymp3.h
+
+cplay_SOURCES = cplay.c
+crecord_SOURCES = crec.c
diff --git a/cplay/cplay.c b/cplay/cplay.c
new file mode 100644
index 000000000000..a017394e5b4f
--- /dev/null
+++ b/cplay/cplay.c
@@ -0,0 +1,294 @@
+/*
+ * tinyplay command line player for compress audio offload in alsa
+ * Copyright (c) 2011-2012, Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU Lesser General Public License,
+ * version 2.1, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU Lesser General Public
+ * License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public License
+ * along with this program; if not, write to
+ * the Free Software Foundation, Inc.,
+ * 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+#include <stdint.h>
+#include <linux/types.h>
+#include <fcntl.h>
+#include <errno.h>
+#include <unistd.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <signal.h>
+#include <stdbool.h>
+#include <getopt.h>
+#include <sys/time.h>
+#include <alsa/asoundlib.h>
+#include <sound/compress_params.h>
+
+#include "tinymp3.h"
+
+static int verbose;
+
+static void usage(void)
+{
+	fprintf(stderr, "usage: cplay [OPTIONS] filename\n"
+		"-c\tcard number\n"
+		"-d\tdevice node\n"
+		"-b\tbuffer size\n"
+		"-f\tfragments\n\n"
+		"-v\tverbose mode\n"
+		"-h\tPrints this help list\n\n"
+		"Example:\n"
+		"\tcplay -c 1 -d 2 test.mp3\n"
+		"\tcplay -f 5 test.mp3\n");
+
+	exit(EXIT_FAILURE);
+}
+
+void play_samples(char *name, unsigned int card, unsigned int device,
+		unsigned long buffer_size, unsigned int frag);
+
+struct mp3_header {
+	uint16_t sync;
+	uint8_t format1;
+	uint8_t format2;
+};
+
+int parse_mp3_header(struct mp3_header *header, unsigned int *num_channels,
+		unsigned int *sample_rate, unsigned int *bit_rate)
+{
+	int ver_idx, mp3_version, layer, bit_rate_idx, sample_rate_idx, channel_idx;
+
+	/* check sync bits */
+	if ((header->sync & MP3_SYNC) != MP3_SYNC) {
+		fprintf(stderr, "Error: Can't find sync word\n");
+		return -1;
+	}
+	ver_idx = (header->sync >> 11) & 0x03;
+	mp3_version = ver_idx == 0 ? MPEG25 : ((ver_idx & 0x1) ? MPEG1 : MPEG2);
+	layer = 4 - ((header->sync >> 9) & 0x03);
+	bit_rate_idx = ((header->format1 >> 4) & 0x0f);
+	sample_rate_idx = ((header->format1 >> 2) & 0x03);
+	channel_idx = ((header->format2 >> 6) & 0x03);
+
+	if (sample_rate_idx == 3 || layer == 4 || bit_rate_idx == 15) {
+		fprintf(stderr, "Error: Can't find valid header\n");
+		return -1;
+	}
+	*num_channels = (channel_idx == MONO ? 1 : 2);
+	*sample_rate = mp3_sample_rates[mp3_version][sample_rate_idx];
+	*bit_rate = (mp3_bit_rates[mp3_version][layer - 1][bit_rate_idx]) * 1000;
+	if (verbose)
+		printf("%s: exit\n", __func__);
+	return 0;
+}
+
+int check_codec_format_supported(unsigned int card, unsigned int device, struct snd_codec *codec)
+{
+	if (snd_compr_is_codec_supported(card, device, COMPRESS_IN, codec) == false) {
+		fprintf(stderr, "Error: This codec or format is not supported by DSP\n");
+		return -1;
+	}
+	return 0;
+}
+
+static int print_time(struct snd_compr *compress)
+{
+	unsigned int avail;
+	struct timespec tstamp;
+
+	if (snd_compr_get_hpointer(compress, &avail, &tstamp) != 0) {
+		fprintf(stderr, "Error querying timestamp\n");
+		fprintf(stderr, "ERR: %s\n", snd_compr_get_error(compress));
+		return -1;
+	} else
+		fprintf(stderr, "DSP played %jd.%jd\n", (intmax_t)tstamp.tv_sec, (intmax_t)tstamp.tv_nsec*1000);
+	return 0;
+}
+
+int main(int argc, char **argv)
+{
+	char *file;
+	unsigned long buffer_size = 0;
+	int c;
+	unsigned int card = 0, device = 0, frag = 0;
+
+
+	if (argc < 2)
+		usage();
+
+	verbose = 0;
+	while ((c = getopt(argc, argv, "hvb:f:c:d:")) != -1) {
+		switch (c) {
+		case 'h':
+			usage();
+			break;
+		case 'b':
+			buffer_size = strtol(optarg, NULL, 0);
+			break;
+		case 'f':
+			frag = strtol(optarg, NULL, 10);
+			break;
+		case 'c':
+			card = strtol(optarg, NULL, 10);
+			break;
+		case 'd':
+			device = strtol(optarg, NULL, 10);
+			break;
+		case 'v':
+			verbose = 1;
+			break;
+		default:
+			exit(EXIT_FAILURE);
+		}
+	}
+	if (optind >= argc)
+		usage();
+
+	file = argv[optind];
+
+	play_samples(file, card, device, buffer_size, frag);
+
+	fprintf(stderr, "Finish Playing.... Close Normally\n");
+	exit(EXIT_SUCCESS);
+}
+
+void play_samples(char *name, unsigned int card, unsigned int device,
+		unsigned long buffer_size, unsigned int frag)
+{
+	struct snd_compr_config config;
+	struct snd_codec codec;
+	struct snd_compr *compress;
+	struct mp3_header header;
+	FILE *file;
+	char *buffer;
+	int size, num_read, wrote;
+	unsigned int channels, rate, bits;
+
+	if (verbose)
+		printf("%s: entry\n", __func__);
+	file = fopen(name, "rb");
+	if (!file) {
+		fprintf(stderr, "Unable to open file '%s'\n", name);
+		exit(EXIT_FAILURE);
+	}
+
+	fread(&header, sizeof(header), 1, file);
+
+	if (parse_mp3_header(&header, &channels, &rate, &bits) == -1) {
+		fclose(file);
+		exit(EXIT_FAILURE);
+	}
+
+	codec.id = SND_AUDIOCODEC_MP3;
+	codec.ch_in = channels;
+	codec.ch_out = channels;
+	codec.sample_rate = rate;
+	if (!codec.sample_rate) {
+		fprintf(stderr, "invalid sample rate %d\n", rate);
+		fclose(file);
+		exit(EXIT_FAILURE);
+	}
+	codec.bit_rate = bits;
+	codec.rate_control = 0;
+	codec.profile = 0;
+	codec.level = 0;
+	codec.ch_mode = 0;
+	codec.format = 0;
+	if ((buffer_size != 0) && (frag != 0)) {
+		config.fragment_size = buffer_size/frag;
+		config.fragments = frag;
+	} else {
+		/* use driver defaults */
+		config.fragment_size = 0;
+		config.fragments = 0;
+	}
+	config.codec = &codec;
+
+	compress = snd_compr_open(card, device, COMPRESS_IN, &config);
+	if (!compress || !snd_compr_is_ready(compress)) {
+		fprintf(stderr, "Unable to open Compress device %d:%d\n",
+				card, device);
+		fprintf(stderr, "ERR: %s\n", snd_compr_get_error(compress));
+		goto FILE_EXIT;
+	};
+	if (verbose)
+		printf("%s: Opened compress device\n", __func__);
+	size = config.fragment_size;
+	buffer = malloc(size * config.fragments);
+	if (!buffer) {
+		fprintf(stderr, "Unable to allocate %d bytes\n", size);
+		goto COMP_EXIT;
+	}
+
+	/* we will write frag fragment_size and then start */
+	num_read = fread(buffer, 1, size * config.fragments, file);
+	if (num_read > 0) {
+		if (verbose)
+			printf("%s: Doing first buffer write of %d\n", __func__, num_read);
+		wrote = snd_compr_write(compress, buffer, num_read);
+		if (wrote < 0) {
+			fprintf(stderr, "Error %d playing sample\n", wrote);
+			fprintf(stderr, "ERR: %s\n", snd_compr_get_error(compress));
+			goto BUF_EXIT;
+		}
+		if (wrote != num_read) {
+			/* TODO: Buufer pointer needs to be set here */
+			fprintf(stderr, "We wrote %d, DSP accepted %d\n", num_read, wrote);
+		}
+	}
+	printf("Playing file %s On Card %u device %u, with buffer of %lu bytes\n",
+			name, card, device, buffer_size);
+	printf("Format %u Channels %u, %u Hz, Bit Rate %d\n",
+			SND_AUDIOCODEC_MP3, channels, rate, bits);
+
+	snd_compr_start(compress);
+	if (verbose)
+		printf("%s: You should hear audio NOW!!!\n", __func__);
+
+	do {
+		num_read = fread(buffer, 1, size, file);
+		if (num_read > 0) {
+			wrote = snd_compr_write(compress, buffer, num_read);
+			if (wrote < 0) {
+				fprintf(stderr, "Error playing sample\n");
+				fprintf(stderr, "ERR: %s\n", snd_compr_get_error(compress));
+				goto BUF_EXIT;
+			}
+			if (wrote != num_read) {
+				/* TODO: Buffer pointer needs to be set here */
+				fprintf(stderr, "We wrote %d, DSP accepted %d\n", num_read, wrote);
+			}
+			if (verbose) {
+				print_time(compress);
+				printf("%s: wrote %d\n", __func__, wrote);
+			}
+		}
+	} while (num_read > 0);
+
+	if (verbose)
+		printf("%s: exit success\n", __func__);
+	/* issue drain if it supports */
+	snd_compr_drain(compress);
+	free(buffer);
+	fclose(file);
+	snd_compr_close(compress);
+	return;
+BUF_EXIT:
+	free(buffer);
+COMP_EXIT:
+	snd_compr_close(compress);
+FILE_EXIT:
+	fclose(file);
+	if (verbose)
+		printf("%s: exit failure\n", __func__);
+	exit(EXIT_FAILURE);
+}
+
diff --git a/cplay/crec.c b/cplay/crec.c
new file mode 100644
index 000000000000..6a3b4a260ceb
--- /dev/null
+++ b/cplay/crec.c
@@ -0,0 +1,449 @@
+/*
+ * crec command line recorder for compress audio record in alsa
+ * Copyright (c) 2011-2012, Intel Corporation
+ * Copyright (c) 2013-2014, Wolfson Microelectronic Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU Lesser General Public License,
+ * version 2.1, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU Lesser General Public
+ * License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public License
+ * along with this program; if not, write to
+ * the Free Software Foundation, Inc.,
+ * 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+#include <stdint.h>
+#include <linux/types.h>
+#include <fcntl.h>
+#include <errno.h>
+#include <unistd.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <signal.h>
+#include <stdbool.h>
+#include <getopt.h>
+#include <sys/time.h>
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <alsa/asoundlib.h>
+#include <sound/compress_params.h>
+
+static int verbose;
+static int file;
+static FILE *finfo;
+static bool streamed;
+
+static const unsigned int DEFAULT_CHANNELS = 1;
+static const unsigned int DEFAULT_RATE = 44100;
+static const unsigned int DEFAULT_FORMAT = SND_PCM_FORMAT_S16_LE;
+
+struct riff_chunk {
+	char desc[4];
+	uint32_t size;
+} __attribute__((__packed__));
+
+struct wave_header {
+	struct {
+		struct riff_chunk chunk;
+		char format[4];
+	} __attribute__((__packed__)) riff;
+
+	struct {
+		struct riff_chunk chunk;
+		uint16_t type;
+		uint16_t channels;
+		uint32_t rate;
+		uint32_t byterate;
+		uint16_t blockalign;
+		uint16_t samplebits;
+	} __attribute__((__packed__)) fmt;
+
+	struct {
+		struct riff_chunk chunk;
+	} __attribute__((__packed__)) data;
+} __attribute__((__packed__));
+
+const struct wave_header blank_wave_header = {
+	.riff = {
+		.chunk = {
+			.desc = "RIFF",
+		},
+		.format = "WAVE",
+	},
+	.fmt = {
+		.chunk = {
+			.desc = "fmt ", /* Note the space is important here */
+			.size = sizeof(blank_wave_header.fmt) -
+				sizeof(blank_wave_header.fmt.chunk),
+		},
+		.type = 0x01,   /* PCM */
+	},
+	.data = {
+		.chunk = {
+			.desc = "data",
+		},
+	},
+};
+
+static void init_wave_header(struct wave_header *header, uint16_t channels,
+			     uint32_t rate, uint16_t samplebits)
+{
+	memcpy(header, &blank_wave_header, sizeof(blank_wave_header));
+
+	header->fmt.channels = channels;
+	header->fmt.rate = rate;
+	header->fmt.byterate = channels * rate * (samplebits / 8);
+	header->fmt.blockalign = channels * (samplebits / 8);
+	header->fmt.samplebits = samplebits;
+}
+
+static void size_wave_header(struct wave_header *header, uint32_t size)
+{
+	header->riff.chunk.size = sizeof(*header) -
+				  sizeof(header->riff.chunk) + size;
+	header->data.chunk.size = size;
+}
+
+static void usage(void)
+{
+	fprintf(stderr, "usage: crecord [OPTIONS] [filename]\n"
+		"-c\tcard number\n"
+		"-d\tdevice node\n"
+		"-b\tbuffer size\n"
+		"-f\tfragments\n"
+		"-v\tverbose mode\n"
+		"-l\tlength of record in seconds\n"
+		"-h\tPrints this help list\n\n"
+		"-C\tSpecify the number of channels (default %u)\n"
+		"-R\tSpecify the sample rate (default %u)\n"
+		"-F\tSpecify the format: S16_LE, S32_LE (default S16_LE)\n\n"
+		"If filename is not given the output is\n"
+		"written to stdout\n\n"
+		"Example:\n"
+		"\tcrec -c 1 -d 2 test.wav\n"
+		"\tcrec -f 5 test.wav\n",
+		DEFAULT_CHANNELS, DEFAULT_RATE);
+
+	exit(EXIT_FAILURE);
+}
+
+static int print_time(struct snd_compr *compress)
+{
+	unsigned int avail;
+	struct timespec tstamp;
+
+	if (snd_compr_get_hpointer(compress, &avail, &tstamp) != 0) {
+		fprintf(stderr, "Error querying timestamp\n");
+		fprintf(stderr, "ERR: %s\n", snd_compr_get_error(compress));
+		return -1;
+	} else {
+		fprintf(finfo, "DSP recorded %jd.%jd\n",
+		       (intmax_t)tstamp.tv_sec, (intmax_t)tstamp.tv_nsec*1000);
+	}
+	return 0;
+}
+
+static int finish_record()
+{
+	struct wave_header header;
+	int ret;
+	size_t nread, written;
+
+	if (!file)
+		return -ENOENT;
+
+	/* can't rewind if streaming to stdout */
+	if (streamed)
+		return 0;
+
+	/* Get amount of data written to file */
+	ret = lseek(file, 0, SEEK_END);
+	if (ret < 0)
+		return -errno;
+
+	written = ret;
+	if (written < sizeof(header))
+		return -ENOENT;
+	written -= sizeof(header);
+
+	/* Sync file header from file */
+	ret = lseek(file, 0, SEEK_SET);
+	if (ret < 0)
+		return -errno;
+
+	nread = read(file, &header, sizeof(header));
+	if (nread != sizeof(header))
+		return -errno;
+
+	/* Update file header */
+	ret = lseek(file, 0, SEEK_SET);
+	if (ret < 0)
+		return -errno;
+
+	size_wave_header(&header, written);
+
+	written = write(file, &header, sizeof(header));
+	if (written != sizeof(header))
+		return -errno;
+
+	return 0;
+}
+
+void capture_samples(char *name, unsigned int card, unsigned int device,
+		     unsigned long buffer_size, unsigned int frag,
+		     unsigned int length, unsigned int rate,
+		     unsigned int channels, unsigned int format)
+{
+	struct snd_compr_config config;
+	struct snd_codec codec;
+	struct snd_compr *compress;
+	struct wave_header header;
+	char *buffer;
+	size_t written;
+	int read, ret;
+	unsigned int size, total_read = 0;
+	unsigned int samplebits;
+
+	switch (format) {
+	case SND_PCM_FORMAT_S32_LE:
+		samplebits = 32;
+		break;
+	default:
+		samplebits = 16;
+		break;
+	}
+
+	/* Convert length from seconds to bytes */
+	length = length * rate * (samplebits / 8) * channels;
+
+	if (verbose)
+		fprintf(finfo, "%s: entry, reading %u bytes\n", __func__, length);
+        if (!name) {
+                file = STDOUT_FILENO;
+        } else {
+	        file = open(name, O_RDWR | O_CREAT, S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP);
+	        if (file == -1) {
+		       fprintf(stderr, "Unable to open file '%s'\n", name);
+		       exit(EXIT_FAILURE);
+	        }
+        }
+
+	/* Write a header, will update with size once record is complete */
+        if (!streamed) {
+	    init_wave_header(&header, channels, rate, samplebits);
+	    written = write(file, &header, sizeof(header));
+	    if (written != sizeof(header)) {
+		fprintf(stderr, "Error writing output file header: %s\n",
+			strerror(errno));
+		goto file_exit;
+	    }
+        }
+
+	memset(&codec, 0, sizeof(codec));
+	memset(&config, 0, sizeof(config));
+	codec.id = SND_AUDIOCODEC_PCM;
+	codec.ch_in = channels;
+	codec.ch_out = channels;
+	codec.sample_rate = rate;
+	if (!codec.sample_rate) {
+		fprintf(stderr, "invalid sample rate %d\n", rate);
+		goto file_exit;
+	}
+	codec.format = format;
+	if ((buffer_size != 0) && (frag != 0)) {
+		config.fragment_size = buffer_size/frag;
+		config.fragments = frag;
+	}
+	config.codec = &codec;
+
+	compress = snd_compr_open(card, device, COMPRESS_OUT, &config);
+	if (!compress || !snd_compr_is_ready(compress)) {
+		fprintf(stderr, "Unable to open Compress device %d:%d\n",
+			card, device);
+		fprintf(stderr, "ERR: %s\n", snd_compr_get_error(compress));
+		goto file_exit;
+	};
+
+	if (verbose)
+		fprintf(finfo, "%s: Opened compress device\n", __func__);
+
+	size = config.fragment_size;
+	buffer = malloc(size * config.fragments);
+	if (!buffer) {
+		fprintf(stderr, "Unable to allocate %d bytes\n", size);
+		goto comp_exit;
+	}
+
+	fprintf(finfo, "Recording file %s On Card %u device %u, with buffer of %lu bytes\n",
+	       name, card, device, buffer_size);
+	fprintf(finfo, "Codec %u Format %u Channels %u, %u Hz\n",
+	       codec.id, codec.format, codec.ch_out, rate);
+
+	snd_compr_start(compress);
+
+	if (verbose)
+		fprintf(finfo, "%s: Capturing audio NOW!!!\n", __func__);
+
+	do {
+		if (length && size > length - total_read)
+			size = length - total_read;
+
+		read = snd_compr_read(compress, buffer, size);
+		if (read < 0) {
+			fprintf(stderr, "Error reading sample\n");
+			fprintf(stderr, "ERR: %s\n", snd_compr_get_error(compress));
+			goto buf_exit;
+		}
+		if ((unsigned int)read != size) {
+			fprintf(stderr, "We read %d, DSP sent %d\n",
+				size, read);
+		}
+
+		if (read > 0) {
+			total_read += read;
+
+			written = write(file, buffer, read);
+			if (written != (size_t)read) {
+				fprintf(stderr, "Error writing output file: %s\n",
+					strerror(errno));
+				goto buf_exit;
+			}
+			if (verbose) {
+				print_time(compress);
+				fprintf(finfo, "%s: read %d\n", __func__, read);
+			}
+		}
+	} while (!length || total_read < length);
+
+	ret = snd_compr_stop(compress);
+	if (ret < 0) {
+		fprintf(stderr, "Error closing stream\n");
+		fprintf(stderr, "ERR: %s\n", snd_compr_get_error(compress));
+	}
+
+	ret = finish_record();
+	if (ret < 0) {
+		fprintf(stderr, "Failed to finish header: %s\n", strerror(ret));
+		goto buf_exit;
+	}
+
+	if (verbose)
+		fprintf(finfo, "%s: exit success\n", __func__);
+
+	free(buffer);
+	close(file);
+	file = 0;
+
+	snd_compr_close(compress);
+
+	return;
+buf_exit:
+	free(buffer);
+comp_exit:
+	snd_compr_close(compress);
+file_exit:
+	close(file);
+
+	if (verbose)
+		fprintf(finfo, "%s: exit failure\n", __func__);
+
+	exit(EXIT_FAILURE);
+}
+
+static void sig_handler(int signum __attribute__ ((unused)))
+{
+	finish_record();
+
+	if (file)
+		close(file);
+
+	_exit(EXIT_FAILURE);
+}
+
+int main(int argc, char **argv)
+{
+	char *file;
+	unsigned long buffer_size = 0;
+	int c;
+	unsigned int card = 0, device = 0, frag = 0, length = 0;
+	unsigned int rate = DEFAULT_RATE, channels = DEFAULT_CHANNELS;
+	unsigned int format = DEFAULT_FORMAT;
+
+	if (signal(SIGINT, sig_handler) == SIG_ERR) {
+		fprintf(stderr, "Error registering signal handler\n");
+		exit(EXIT_FAILURE);
+	}
+
+	if (argc < 1)
+		usage();
+
+	verbose = 0;
+	while ((c = getopt(argc, argv, "hvl:R:C:F:b:f:c:d:")) != -1) {
+		switch (c) {
+		case 'h':
+			usage();
+			break;
+		case 'b':
+			buffer_size = strtol(optarg, NULL, 0);
+			break;
+		case 'f':
+			frag = strtol(optarg, NULL, 10);
+			break;
+		case 'c':
+			card = strtol(optarg, NULL, 10);
+			break;
+		case 'd':
+			device = strtol(optarg, NULL, 10);
+			break;
+		case 'v':
+			verbose = 1;
+			break;
+		case 'l':
+			length = strtol(optarg, NULL, 10);
+			break;
+		case 'R':
+			rate = strtol(optarg, NULL, 10);
+			break;
+		case 'C':
+			channels = strtol(optarg, NULL, 10);
+			break;
+		case 'F':
+			if (strcmp(optarg, "S16_LE") == 0) {
+				format = SND_PCM_FORMAT_S16_LE;
+			} else if (strcmp(optarg, "S32_LE") == 0) {
+				format = SND_PCM_FORMAT_S32_LE;
+			} else {
+				fprintf(stderr, "Unrecognised format: %s\n",
+					optarg);
+				usage();
+			}
+			break;
+		default:
+			exit(EXIT_FAILURE);
+		}
+	}
+	if (optind >= argc) {
+		file = NULL;
+		finfo = fopen("/dev/null", "w");
+		streamed = true;
+	} else {
+		file = argv[optind];
+		finfo = stdout;
+		streamed = false;
+	}
+
+	capture_samples(file, card, device, buffer_size, frag, length,
+			rate, channels, format);
+
+	fprintf(finfo, "Finish capturing... Close Normally\n");
+
+	exit(EXIT_SUCCESS);
+}
+
diff --git a/cplay/tinymp3.h b/cplay/tinymp3.h
new file mode 100644
index 000000000000..13afaec2757d
--- /dev/null
+++ b/cplay/tinymp3.h
@@ -0,0 +1,72 @@
+/*
+ * mp3 header and parsing
+ * Copyright (c) 2011-2012, Intel Corporation.
+ *
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU Lesser General Public License,
+ * version 2.1, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU Lesser General Public
+ * License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public License
+ * along with this program; if not, write to
+ * the Free Software Foundation, Inc.,
+ * 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+
+#ifndef __TINYMP3_H
+#define __TINYMP3_H
+
+#if defined(__cplusplus)
+extern "C" {
+#endif
+
+
+#define MP3_SYNC 0xe0ff
+
+const int mp3_sample_rates[3][3] = {
+	{44100, 48000, 32000},        /* MPEG-1 */
+	{22050, 24000, 16000},        /* MPEG-2 */
+	{11025, 12000,  8000},        /* MPEG-2.5 */
+};
+
+const int mp3_bit_rates[3][3][15] = {
+	{
+		/* MPEG-1 */
+		{  0, 32, 64, 96, 128, 160, 192, 224, 256, 288, 320, 352, 384, 416, 448}, /* Layer 1 */
+		{  0, 32, 48, 56, 64, 80, 96, 112, 128, 160, 192, 224, 256, 320, 384}, /* Layer 2 */
+		{  0, 32, 40, 48, 56, 64, 80, 96, 112, 128, 160, 192, 224, 256, 320}, /* Layer 3 */
+	},
+	{
+		/* MPEG-2 */
+		{  0, 32, 48, 56, 64, 80, 96, 112, 128, 144, 160, 176, 192, 224, 256}, /* Layer 1 */
+		{  0,  8, 16, 24, 32, 40, 48, 56, 64, 80, 96, 112, 128, 144, 160}, /* Layer 2 */
+		{  0,  8, 16, 24, 32, 40, 48, 56, 64, 80, 96, 112, 128, 144, 160}, /* Layer 3 */
+	},
+	{
+		/* MPEG-2.5 */
+		{  0, 32, 48, 56, 64, 80, 96, 112, 128, 144, 160, 176, 192, 224, 256}, /* Layer 1 */
+		{  0,  8, 16, 24, 32, 40, 48, 56, 64, 80, 96, 112, 128, 144, 160}, /* Layer 2 */
+		{  0,  8, 16, 24, 32, 40, 48, 56, 64, 80, 96, 112, 128, 144, 160}, /* Layer 3 */
+	},
+};
+
+enum mpeg_version {
+	MPEG1  = 0,
+	MPEG2  = 1,
+	MPEG25 = 2
+};
+
+enum mp3_stereo_mode {
+	STEREO = 0x00,
+	JOINT = 0x01,
+	DUAL = 0x02,
+	MONO = 0x03
+};
+
+#endif
-- 
2.1.0

Re: [ALSA-UTILS][PATCH] Add support for cplay and crecord

[Vinod Koul]

On Wed, Mar 04, 2015 at 03:36:00PM +0000, Qais Yousef wrote:
> cplay and crecord use compress offload API to play and record compressed audio.
> 
> They're based on cplay and crec from tinycompress library using LGPL license.
> 
> For now cplay only supports playing mp3 files.
> 
> Signed-off-by: Qais Yousef <qais.yousef@imgtec.com>
> Cc: Takashi Iwai <tiwai@suse.de>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Mark Brown <broonie@kernel.org>
> ---
> I renamed crec to crecord also to match aplay and arecord, hopefully
> you don't mind Vinod.
No thats fine..

> 
> This patch is dependent on my other patch that adds support for compress offload
> to alsa-lib.
And where is that, should have preceded this
> 
> I needed to include <sound/compress_params.h> in cplay.c and crec.c
> but I couldn't find an example of any C file which directly includes <sound/*.h>
> The norm seems to be to just include <alsa/asoundlib.h>. Do I need to
> redefine structs from <sound/compress_params.h> to newly added <alsa/compress.h>?
> <alsa/pcm.h> seems to redefine structs from <sound/asound.h>.
These are kernel headers and should be in your include path if you have
those installed
> 
> I could only test cplay but have no means to test crecord at the moment.
> 
>  Makefile.am       |   3 +
>  configure.ac      |   6 +-
>  cplay/Makefile.am |  14 ++
>  cplay/cplay.c     | 294 +++++++++++++++++++++++++++++++++++
>  cplay/crec.c      | 449 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  cplay/tinymp3.h   |  72 +++++++++
>  6 files changed, 837 insertions(+), 1 deletion(-)
>  create mode 100644 cplay/Makefile.am
>  create mode 100644 cplay/cplay.c
>  create mode 100644 cplay/crec.c
>  create mode 100644 cplay/tinymp3.h

Okay here is where we need discussion on the future course. If we do this
then we end up in two code bases, something I would not encourage!

On the other hand if we add the make file changes to tinycompress or if
required split this into two, lib and tools and then package lib part into
alsa-lib and players into tools, that way we can have single code base. That
was my intent behind ensuring that this is dual licensed.

Takashi, is that something we could achieve? I think last time we discussed
this topic you seemed okay with this, only thing was tinycompress lacks
proper make support which we can add

-- 
~Vinod

Re: [ALSA-UTILS][PATCH] Add support for cplay and crecord

[Takashi Iwai]

At Wed, 4 Mar 2015 21:40:13 +0530,
Vinod Koul wrote:
> 
> On Wed, Mar 04, 2015 at 03:36:00PM +0000, Qais Yousef wrote:
> > cplay and crecord use compress offload API to play and record compressed audio.
> > 
> > They're based on cplay and crec from tinycompress library using LGPL license.
> > 
> > For now cplay only supports playing mp3 files.
> > 
> > Signed-off-by: Qais Yousef <qais.yousef@imgtec.com>
> > Cc: Takashi Iwai <tiwai@suse.de>
> > Cc: Vinod Koul <vinod.koul@intel.com>
> > Cc: Mark Brown <broonie@kernel.org>
> > ---
> > I renamed crec to crecord also to match aplay and arecord, hopefully
> > you don't mind Vinod.
> No thats fine..
> 
> > 
> > This patch is dependent on my other patch that adds support for compress offload
> > to alsa-lib.
> And where is that, should have preceded this
> > 
> > I needed to include <sound/compress_params.h> in cplay.c and crec.c
> > but I couldn't find an example of any C file which directly includes <sound/*.h>
> > The norm seems to be to just include <alsa/asoundlib.h>. Do I need to
> > redefine structs from <sound/compress_params.h> to newly added <alsa/compress.h>?
> > <alsa/pcm.h> seems to redefine structs from <sound/asound.h>.
> These are kernel headers and should be in your include path if you have
> those installed

This can't be guaranteed because each kernel may provide a different
set of include files.  Currently alsa-lib is packaged as
self-contained so that it can be built with less dependency and
provide user-space also build without kernel headers.  That said, 
user-space apps should read only alsa/*.h, not sound/*.h in general,
except for the very h/w-specific one.  It's an intended separation.
(But it's a waste of spaces, yes.)


Takashi

Re: [ALSA-UTILS][PATCH] Add support for cplay and crecord

[Qais Yousef]

On 03/04/2015 04:10 PM, Vinod Koul wrote:
> On Wed, Mar 04, 2015 at 03:36:00PM +0000, Qais Yousef wrote:
>> cplay and crecord use compress offload API to play and record compressed audio.
>>
>> They're based on cplay and crec from tinycompress library using LGPL license.
>>
>> For now cplay only supports playing mp3 files.
>>
>> Signed-off-by: Qais Yousef <qais.yousef@imgtec.com>
>> Cc: Takashi Iwai <tiwai@suse.de>
>> Cc: Vinod Koul <vinod.koul@intel.com>
>> Cc: Mark Brown <broonie@kernel.org>
>> ---
>> I renamed crec to crecord also to match aplay and arecord, hopefully
>> you don't mind Vinod.
> No thats fine..
>
>> This patch is dependent on my other patch that adds support for compress offload
>> to alsa-lib.
> And where is that, should have preceded this

Hmm not sure what went wrong. I resent it. Seems I have some emailer 
issues as I had this problem before.
Hopefully you received it now.

>> I needed to include <sound/compress_params.h> in cplay.c and crec.c
>> but I couldn't find an example of any C file which directly includes <sound/*.h>
>> The norm seems to be to just include <alsa/asoundlib.h>. Do I need to
>> redefine structs from <sound/compress_params.h> to newly added <alsa/compress.h>?
>> <alsa/pcm.h> seems to redefine structs from <sound/asound.h>.
> These are kernel headers and should be in your include path if you have
> those installed
>> I could only test cplay but have no means to test crecord at the moment.
>>
>>   Makefile.am       |   3 +
>>   configure.ac      |   6 +-
>>   cplay/Makefile.am |  14 ++
>>   cplay/cplay.c     | 294 +++++++++++++++++++++++++++++++++++
>>   cplay/crec.c      | 449 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>   cplay/tinymp3.h   |  72 +++++++++
>>   6 files changed, 837 insertions(+), 1 deletion(-)
>>   create mode 100644 cplay/Makefile.am
>>   create mode 100644 cplay/cplay.c
>>   create mode 100644 cplay/crec.c
>>   create mode 100644 cplay/tinymp3.h
> Okay here is where we need discussion on the future course. If we do this
> then we end up in two code bases, something I would not encourage!
>
> On the other hand if we add the make file changes to tinycompress or if
> required split this into two, lib and tools and then package lib part into
> alsa-lib and players into tools, that way we can have single code base. That
> was my intent behind ensuring that this is dual licensed.

I'm not sure I follow you completely here. You mean keep cplay and crec 
in tinycompress with the dual licensing but only merge the lib part 
(which my other patch does) into alsa-lib? For me having this lib part 
into alsa-lib is the important bit. Moving crec and cplay to alsa-utils 
was something I thought would be useful but maybe not.

Thanks,
Qais

>
> Takashi, is that something we could achieve? I think last time we discussed
> this topic you seemed okay with this, only thing was tinycompress lacks
> proper make support which we can add
>

Re: [ALSA-UTILS][PATCH] Add support for cplay and crecord

[Vinod Koul]

On Wed, Mar 04, 2015 at 04:34:41PM +0000, Qais Yousef wrote:
> On 03/04/2015 04:10 PM, Vinod Koul wrote:
> >On Wed, Mar 04, 2015 at 03:36:00PM +0000, Qais Yousef wrote:
> >>cplay and crecord use compress offload API to play and record compressed audio.
> >>
> >>They're based on cplay and crec from tinycompress library using LGPL license.
> >>
> >>For now cplay only supports playing mp3 files.
> >>
> >>Signed-off-by: Qais Yousef <qais.yousef@imgtec.com>
> >>Cc: Takashi Iwai <tiwai@suse.de>
> >>Cc: Vinod Koul <vinod.koul@intel.com>
> >>Cc: Mark Brown <broonie@kernel.org>
> >>---
> >>I renamed crec to crecord also to match aplay and arecord, hopefully
> >>you don't mind Vinod.
> >No thats fine..
> >
> >>This patch is dependent on my other patch that adds support for compress offload
> >>to alsa-lib.
> >And where is that, should have preceded this
> 
> Hmm not sure what went wrong. I resent it. Seems I have some emailer
> issues as I had this problem before.
> Hopefully you received it now.
> 
> >>I needed to include <sound/compress_params.h> in cplay.c and crec.c
> >>but I couldn't find an example of any C file which directly includes <sound/*.h>
> >>The norm seems to be to just include <alsa/asoundlib.h>. Do I need to
> >>redefine structs from <sound/compress_params.h> to newly added <alsa/compress.h>?
> >><alsa/pcm.h> seems to redefine structs from <sound/asound.h>.
> >These are kernel headers and should be in your include path if you have
> >those installed
> >>I could only test cplay but have no means to test crecord at the moment.
> >>
> >>  Makefile.am       |   3 +
> >>  configure.ac      |   6 +-
> >>  cplay/Makefile.am |  14 ++
> >>  cplay/cplay.c     | 294 +++++++++++++++++++++++++++++++++++
> >>  cplay/crec.c      | 449 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >>  cplay/tinymp3.h   |  72 +++++++++
> >>  6 files changed, 837 insertions(+), 1 deletion(-)
> >>  create mode 100644 cplay/Makefile.am
> >>  create mode 100644 cplay/cplay.c
> >>  create mode 100644 cplay/crec.c
> >>  create mode 100644 cplay/tinymp3.h
> >Okay here is where we need discussion on the future course. If we do this
> >then we end up in two code bases, something I would not encourage!
> >
> >On the other hand if we add the make file changes to tinycompress or if
> >required split this into two, lib and tools and then package lib part into
> >alsa-lib and players into tools, that way we can have single code base. That
> >was my intent behind ensuring that this is dual licensed.
> 
> I'm not sure I follow you completely here. You mean keep cplay and
> crec in tinycompress with the dual licensing but only merge the lib
> part (which my other patch does) into alsa-lib? For me having this
> lib part into alsa-lib is the important bit. Moving crec and cplay
> to alsa-utils was something I thought would be useful but maybe not.
Not that

Since alsa splits lib and tools, in order to take this into alsa-libs we
need to split tinycompress, to something like lib and tool part.

Then alsa-lib can import the lib part of tinycompress. Please note I am not
saying we should copy or move code into alsa-lib.
The reason for that is
1. copying code will cause more maintaince of same code in two places :(
2. moving into alsa-lib is not an option as existing users like android will
suffer as they dont use alsa-lib

So I think, while building and packaging alsa-library and tools we can
import the tinycompress using LGPL license and use that to give complete
library on Linux to users

Takashi, can we get you blessing for this approach before we embark on this,
or any other better ideas?

-- 
~Vinod

Re: [ALSA-UTILS][PATCH] Add support for cplay and crecord

[Jaroslav Kysela]

Dne 5.3.2015 v 08:00 Vinod Koul napsal(a):
> On Wed, Mar 04, 2015 at 04:34:41PM +0000, Qais Yousef wrote:
>> On 03/04/2015 04:10 PM, Vinod Koul wrote:
>>> On Wed, Mar 04, 2015 at 03:36:00PM +0000, Qais Yousef wrote:
>>>> cplay and crecord use compress offload API to play and record compressed audio.
>>>>
>>>> They're based on cplay and crec from tinycompress library using LGPL license.
>>>>
>>>> For now cplay only supports playing mp3 files.
>>>>
>>>> Signed-off-by: Qais Yousef <qais.yousef@imgtec.com>
>>>> Cc: Takashi Iwai <tiwai@suse.de>
>>>> Cc: Vinod Koul <vinod.koul@intel.com>
>>>> Cc: Mark Brown <broonie@kernel.org>
>>>> ---
>>>> I renamed crec to crecord also to match aplay and arecord, hopefully
>>>> you don't mind Vinod.
>>> No thats fine..
>>>
>>>> This patch is dependent on my other patch that adds support for compress offload
>>>> to alsa-lib.
>>> And where is that, should have preceded this
>>
>> Hmm not sure what went wrong. I resent it. Seems I have some emailer
>> issues as I had this problem before.
>> Hopefully you received it now.
>>
>>>> I needed to include <sound/compress_params.h> in cplay.c and crec.c
>>>> but I couldn't find an example of any C file which directly includes <sound/*.h>
>>>> The norm seems to be to just include <alsa/asoundlib.h>. Do I need to
>>>> redefine structs from <sound/compress_params.h> to newly added <alsa/compress.h>?
>>>> <alsa/pcm.h> seems to redefine structs from <sound/asound.h>.
>>> These are kernel headers and should be in your include path if you have
>>> those installed
>>>> I could only test cplay but have no means to test crecord at the moment.
>>>>
>>>>  Makefile.am       |   3 +
>>>>  configure.ac      |   6 +-
>>>>  cplay/Makefile.am |  14 ++
>>>>  cplay/cplay.c     | 294 +++++++++++++++++++++++++++++++++++
>>>>  cplay/crec.c      | 449 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>  cplay/tinymp3.h   |  72 +++++++++
>>>>  6 files changed, 837 insertions(+), 1 deletion(-)
>>>>  create mode 100644 cplay/Makefile.am
>>>>  create mode 100644 cplay/cplay.c
>>>>  create mode 100644 cplay/crec.c
>>>>  create mode 100644 cplay/tinymp3.h
>>> Okay here is where we need discussion on the future course. If we do this
>>> then we end up in two code bases, something I would not encourage!
>>>
>>> On the other hand if we add the make file changes to tinycompress or if
>>> required split this into two, lib and tools and then package lib part into
>>> alsa-lib and players into tools, that way we can have single code base. That
>>> was my intent behind ensuring that this is dual licensed.
>>
>> I'm not sure I follow you completely here. You mean keep cplay and
>> crec in tinycompress with the dual licensing but only merge the lib
>> part (which my other patch does) into alsa-lib? For me having this
>> lib part into alsa-lib is the important bit. Moving crec and cplay
>> to alsa-utils was something I thought would be useful but maybe not.
> Not that
> 
> Since alsa splits lib and tools, in order to take this into alsa-libs we
> need to split tinycompress, to something like lib and tool part.
> 
> Then alsa-lib can import the lib part of tinycompress. Please note I am not
> saying we should copy or move code into alsa-lib.
> The reason for that is
> 1. copying code will cause more maintaince of same code in two places :(
> 2. moving into alsa-lib is not an option as existing users like android will
> suffer as they dont use alsa-lib
> 
> So I think, while building and packaging alsa-library and tools we can
> import the tinycompress using LGPL license and use that to give complete
> library on Linux to users
> 
> Takashi, can we get you blessing for this approach before we embark on this,
> or any other better ideas?

The problem is if the code is not duplicated, then the parts of the
alsa-lib binary will be dual-licenced. I don't think that it's the right
way.

And if the code is duplicated, then patch authors for all next updates
in both libraries (alsa-lib, tinycompress) must be asked for permissions
to change code licence for the merge to the second library.

I think that a plugin-style extension should be created here (so
tinycompress will be used at runtime as the dynamic library).

compress API -> tinycompress plugin -> tinycompress .so functions

This will allow us also to create another plugins in future.

					Jaroslav


-- 
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project; Red Hat, Inc.

Re: [ALSA-UTILS][PATCH] Add support for cplay and crecord

[Vinod Koul]

On Thu, Mar 05, 2015 at 08:43:18AM +0100, Jaroslav Kysela wrote:
> Dne 5.3.2015 v 08:00 Vinod Koul napsal(a):
> > On Wed, Mar 04, 2015 at 04:34:41PM +0000, Qais Yousef wrote:
> >> On 03/04/2015 04:10 PM, Vinod Koul wrote:
> >>> On Wed, Mar 04, 2015 at 03:36:00PM +0000, Qais Yousef wrote:
> >>>> cplay and crecord use compress offload API to play and record compressed audio.
> >>>>
> >>>> They're based on cplay and crec from tinycompress library using LGPL license.
> >>>>
> >>>> For now cplay only supports playing mp3 files.
> >>>>
> >>>> Signed-off-by: Qais Yousef <qais.yousef@imgtec.com>
> >>>> Cc: Takashi Iwai <tiwai@suse.de>
> >>>> Cc: Vinod Koul <vinod.koul@intel.com>
> >>>> Cc: Mark Brown <broonie@kernel.org>
> >>>> ---
> >>>> I renamed crec to crecord also to match aplay and arecord, hopefully
> >>>> you don't mind Vinod.
> >>> No thats fine..
> >>>
> >>>> This patch is dependent on my other patch that adds support for compress offload
> >>>> to alsa-lib.
> >>> And where is that, should have preceded this
> >>
> >> Hmm not sure what went wrong. I resent it. Seems I have some emailer
> >> issues as I had this problem before.
> >> Hopefully you received it now.
> >>
> >>>> I needed to include <sound/compress_params.h> in cplay.c and crec.c
> >>>> but I couldn't find an example of any C file which directly includes <sound/*.h>
> >>>> The norm seems to be to just include <alsa/asoundlib.h>. Do I need to
> >>>> redefine structs from <sound/compress_params.h> to newly added <alsa/compress.h>?
> >>>> <alsa/pcm.h> seems to redefine structs from <sound/asound.h>.
> >>> These are kernel headers and should be in your include path if you have
> >>> those installed
> >>>> I could only test cplay but have no means to test crecord at the moment.
> >>>>
> >>>>  Makefile.am       |   3 +
> >>>>  configure.ac      |   6 +-
> >>>>  cplay/Makefile.am |  14 ++
> >>>>  cplay/cplay.c     | 294 +++++++++++++++++++++++++++++++++++
> >>>>  cplay/crec.c      | 449 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >>>>  cplay/tinymp3.h   |  72 +++++++++
> >>>>  6 files changed, 837 insertions(+), 1 deletion(-)
> >>>>  create mode 100644 cplay/Makefile.am
> >>>>  create mode 100644 cplay/cplay.c
> >>>>  create mode 100644 cplay/crec.c
> >>>>  create mode 100644 cplay/tinymp3.h
> >>> Okay here is where we need discussion on the future course. If we do this
> >>> then we end up in two code bases, something I would not encourage!
> >>>
> >>> On the other hand if we add the make file changes to tinycompress or if
> >>> required split this into two, lib and tools and then package lib part into
> >>> alsa-lib and players into tools, that way we can have single code base. That
> >>> was my intent behind ensuring that this is dual licensed.
> >>
> >> I'm not sure I follow you completely here. You mean keep cplay and
> >> crec in tinycompress with the dual licensing but only merge the lib
> >> part (which my other patch does) into alsa-lib? For me having this
> >> lib part into alsa-lib is the important bit. Moving crec and cplay
> >> to alsa-utils was something I thought would be useful but maybe not.
> > Not that
> > 
> > Since alsa splits lib and tools, in order to take this into alsa-libs we
> > need to split tinycompress, to something like lib and tool part.
> > 
> > Then alsa-lib can import the lib part of tinycompress. Please note I am not
> > saying we should copy or move code into alsa-lib.
> > The reason for that is
> > 1. copying code will cause more maintaince of same code in two places :(
> > 2. moving into alsa-lib is not an option as existing users like android will
> > suffer as they dont use alsa-lib
> > 
> > So I think, while building and packaging alsa-library and tools we can
> > import the tinycompress using LGPL license and use that to give complete
> > library on Linux to users
> > 
> > Takashi, can we get you blessing for this approach before we embark on this,
> > or any other better ideas?
> 
> The problem is if the code is not duplicated, then the parts of the
> alsa-lib binary will be dual-licenced. I don't think that it's the right
> way.
> 
> And if the code is duplicated, then patch authors for all next updates
> in both libraries (alsa-lib, tinycompress) must be asked for permissions
> to change code licence for the merge to the second library.
> 
> I think that a plugin-style extension should be created here (so
> tinycompress will be used at runtime as the dynamic library).
> 
> compress API -> tinycompress plugin -> tinycompress .so functions
> 
> This will allow us also to create another plugins in future.
That does solve the issue for me as well. The intent is to provide
compressed functionality within alsa-libs so asa plugin that can work very
well...

Any other thoughts... ?

-- 
~Vinod

Re: [ALSA-UTILS][PATCH] Add support for cplay and crecord

[Takashi Iwai]

At Thu, 5 Mar 2015 14:00:54 +0530,
Vinod Koul wrote:
> 
> On Thu, Mar 05, 2015 at 08:43:18AM +0100, Jaroslav Kysela wrote:
> > Dne 5.3.2015 v 08:00 Vinod Koul napsal(a):
> > > On Wed, Mar 04, 2015 at 04:34:41PM +0000, Qais Yousef wrote:
> > >> On 03/04/2015 04:10 PM, Vinod Koul wrote:
> > >>> On Wed, Mar 04, 2015 at 03:36:00PM +0000, Qais Yousef wrote:
> > >>>> cplay and crecord use compress offload API to play and record compressed audio.
> > >>>>
> > >>>> They're based on cplay and crec from tinycompress library using LGPL license.
> > >>>>
> > >>>> For now cplay only supports playing mp3 files.
> > >>>>
> > >>>> Signed-off-by: Qais Yousef <qais.yousef@imgtec.com>
> > >>>> Cc: Takashi Iwai <tiwai@suse.de>
> > >>>> Cc: Vinod Koul <vinod.koul@intel.com>
> > >>>> Cc: Mark Brown <broonie@kernel.org>
> > >>>> ---
> > >>>> I renamed crec to crecord also to match aplay and arecord, hopefully
> > >>>> you don't mind Vinod.
> > >>> No thats fine..
> > >>>
> > >>>> This patch is dependent on my other patch that adds support for compress offload
> > >>>> to alsa-lib.
> > >>> And where is that, should have preceded this
> > >>
> > >> Hmm not sure what went wrong. I resent it. Seems I have some emailer
> > >> issues as I had this problem before.
> > >> Hopefully you received it now.
> > >>
> > >>>> I needed to include <sound/compress_params.h> in cplay.c and crec.c
> > >>>> but I couldn't find an example of any C file which directly includes <sound/*.h>
> > >>>> The norm seems to be to just include <alsa/asoundlib.h>. Do I need to
> > >>>> redefine structs from <sound/compress_params.h> to newly added <alsa/compress.h>?
> > >>>> <alsa/pcm.h> seems to redefine structs from <sound/asound.h>.
> > >>> These are kernel headers and should be in your include path if you have
> > >>> those installed
> > >>>> I could only test cplay but have no means to test crecord at the moment.
> > >>>>
> > >>>>  Makefile.am       |   3 +
> > >>>>  configure.ac      |   6 +-
> > >>>>  cplay/Makefile.am |  14 ++
> > >>>>  cplay/cplay.c     | 294 +++++++++++++++++++++++++++++++++++
> > >>>>  cplay/crec.c      | 449 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > >>>>  cplay/tinymp3.h   |  72 +++++++++
> > >>>>  6 files changed, 837 insertions(+), 1 deletion(-)
> > >>>>  create mode 100644 cplay/Makefile.am
> > >>>>  create mode 100644 cplay/cplay.c
> > >>>>  create mode 100644 cplay/crec.c
> > >>>>  create mode 100644 cplay/tinymp3.h
> > >>> Okay here is where we need discussion on the future course. If we do this
> > >>> then we end up in two code bases, something I would not encourage!
> > >>>
> > >>> On the other hand if we add the make file changes to tinycompress or if
> > >>> required split this into two, lib and tools and then package lib part into
> > >>> alsa-lib and players into tools, that way we can have single code base. That
> > >>> was my intent behind ensuring that this is dual licensed.
> > >>
> > >> I'm not sure I follow you completely here. You mean keep cplay and
> > >> crec in tinycompress with the dual licensing but only merge the lib
> > >> part (which my other patch does) into alsa-lib? For me having this
> > >> lib part into alsa-lib is the important bit. Moving crec and cplay
> > >> to alsa-utils was something I thought would be useful but maybe not.
> > > Not that
> > > 
> > > Since alsa splits lib and tools, in order to take this into alsa-libs we
> > > need to split tinycompress, to something like lib and tool part.
> > > 
> > > Then alsa-lib can import the lib part of tinycompress. Please note I am not
> > > saying we should copy or move code into alsa-lib.
> > > The reason for that is
> > > 1. copying code will cause more maintaince of same code in two places :(
> > > 2. moving into alsa-lib is not an option as existing users like android will
> > > suffer as they dont use alsa-lib
> > > 
> > > So I think, while building and packaging alsa-library and tools we can
> > > import the tinycompress using LGPL license and use that to give complete
> > > library on Linux to users
> > > 
> > > Takashi, can we get you blessing for this approach before we embark on this,
> > > or any other better ideas?
> > 
> > The problem is if the code is not duplicated, then the parts of the
> > alsa-lib binary will be dual-licenced. I don't think that it's the right
> > way.
> > 
> > And if the code is duplicated, then patch authors for all next updates
> > in both libraries (alsa-lib, tinycompress) must be asked for permissions
> > to change code licence for the merge to the second library.
> > 
> > I think that a plugin-style extension should be created here (so
> > tinycompress will be used at runtime as the dynamic library).
> > 
> > compress API -> tinycompress plugin -> tinycompress .so functions
> > 
> > This will allow us also to create another plugins in future.
> That does solve the issue for me as well. The intent is to provide
> compressed functionality within alsa-libs so asa plugin that can work very
> well...
> 
> Any other thoughts... ?

Well, tinycompress itself is merely a thin layer covering the kernel
ABI.  So, writing a plugin infrastructure itself already achieves the
whole rewrite of tinycompress library.  What else remains as a plugin
content?


Takashi

Re: [ALSA-UTILS][PATCH] Add support for cplay and crecord

[Qais Yousef]

On 03/05/2015 08:52 AM, Takashi Iwai wrote:
> At Thu, 5 Mar 2015 14:00:54 +0530,
> Vinod Koul wrote:
>> On Thu, Mar 05, 2015 at 08:43:18AM +0100, Jaroslav Kysela wrote:
>>> Dne 5.3.2015 v 08:00 Vinod Koul napsal(a):
>>>> On Wed, Mar 04, 2015 at 04:34:41PM +0000, Qais Yousef wrote:
>>>>> On 03/04/2015 04:10 PM, Vinod Koul wrote:
>>>>>> On Wed, Mar 04, 2015 at 03:36:00PM +0000, Qais Yousef wrote:
>>>>>>> cplay and crecord use compress offload API to play and record compressed audio.
>>>>>>>
>>>>>>> They're based on cplay and crec from tinycompress library using LGPL license.
>>>>>>>
>>>>>>> For now cplay only supports playing mp3 files.
>>>>>>>
>>>>>>> Signed-off-by: Qais Yousef <qais.yousef@imgtec.com>
>>>>>>> Cc: Takashi Iwai <tiwai@suse.de>
>>>>>>> Cc: Vinod Koul <vinod.koul@intel.com>
>>>>>>> Cc: Mark Brown <broonie@kernel.org>
>>>>>>> ---
>>>>>>> I renamed crec to crecord also to match aplay and arecord, hopefully
>>>>>>> you don't mind Vinod.
>>>>>> No thats fine..
>>>>>>
>>>>>>> This patch is dependent on my other patch that adds support for compress offload
>>>>>>> to alsa-lib.
>>>>>> And where is that, should have preceded this
>>>>> Hmm not sure what went wrong. I resent it. Seems I have some emailer
>>>>> issues as I had this problem before.
>>>>> Hopefully you received it now.
>>>>>
>>>>>>> I needed to include <sound/compress_params.h> in cplay.c and crec.c
>>>>>>> but I couldn't find an example of any C file which directly includes <sound/*.h>
>>>>>>> The norm seems to be to just include <alsa/asoundlib.h>. Do I need to
>>>>>>> redefine structs from <sound/compress_params.h> to newly added <alsa/compress.h>?
>>>>>>> <alsa/pcm.h> seems to redefine structs from <sound/asound.h>.
>>>>>> These are kernel headers and should be in your include path if you have
>>>>>> those installed
>>>>>>> I could only test cplay but have no means to test crecord at the moment.
>>>>>>>
>>>>>>>   Makefile.am       |   3 +
>>>>>>>   configure.ac      |   6 +-
>>>>>>>   cplay/Makefile.am |  14 ++
>>>>>>>   cplay/cplay.c     | 294 +++++++++++++++++++++++++++++++++++
>>>>>>>   cplay/crec.c      | 449 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>>>>   cplay/tinymp3.h   |  72 +++++++++
>>>>>>>   6 files changed, 837 insertions(+), 1 deletion(-)
>>>>>>>   create mode 100644 cplay/Makefile.am
>>>>>>>   create mode 100644 cplay/cplay.c
>>>>>>>   create mode 100644 cplay/crec.c
>>>>>>>   create mode 100644 cplay/tinymp3.h
>>>>>> Okay here is where we need discussion on the future course. If we do this
>>>>>> then we end up in two code bases, something I would not encourage!
>>>>>>
>>>>>> On the other hand if we add the make file changes to tinycompress or if
>>>>>> required split this into two, lib and tools and then package lib part into
>>>>>> alsa-lib and players into tools, that way we can have single code base. That
>>>>>> was my intent behind ensuring that this is dual licensed.
>>>>> I'm not sure I follow you completely here. You mean keep cplay and
>>>>> crec in tinycompress with the dual licensing but only merge the lib
>>>>> part (which my other patch does) into alsa-lib? For me having this
>>>>> lib part into alsa-lib is the important bit. Moving crec and cplay
>>>>> to alsa-utils was something I thought would be useful but maybe not.
>>>> Not that
>>>>
>>>> Since alsa splits lib and tools, in order to take this into alsa-libs we
>>>> need to split tinycompress, to something like lib and tool part.
>>>>
>>>> Then alsa-lib can import the lib part of tinycompress. Please note I am not
>>>> saying we should copy or move code into alsa-lib.
>>>> The reason for that is
>>>> 1. copying code will cause more maintaince of same code in two places :(
>>>> 2. moving into alsa-lib is not an option as existing users like android will
>>>> suffer as they dont use alsa-lib
>>>>
>>>> So I think, while building and packaging alsa-library and tools we can
>>>> import the tinycompress using LGPL license and use that to give complete
>>>> library on Linux to users
>>>>
>>>> Takashi, can we get you blessing for this approach before we embark on this,
>>>> or any other better ideas?
>>> The problem is if the code is not duplicated, then the parts of the
>>> alsa-lib binary will be dual-licenced. I don't think that it's the right
>>> way.
>>>
>>> And if the code is duplicated, then patch authors for all next updates
>>> in both libraries (alsa-lib, tinycompress) must be asked for permissions
>>> to change code licence for the merge to the second library.
>>>
>>> I think that a plugin-style extension should be created here (so
>>> tinycompress will be used at runtime as the dynamic library).
>>>
>>> compress API -> tinycompress plugin -> tinycompress .so functions
>>>
>>> This will allow us also to create another plugins in future.
>> That does solve the issue for me as well. The intent is to provide
>> compressed functionality within alsa-libs so asa plugin that can work very
>> well...
>>
>> Any other thoughts... ?
> Well, tinycompress itself is merely a thin layer covering the kernel
> ABI.  So, writing a plugin infrastructure itself already achieves the
> whole rewrite of tinycompress library.  What else remains as a plugin
> content?
>
>
> Takashi

OK reading a bit more about dual license what I understood is that it's 
ok for alsa-lib to choose redistribute tinycompress as LGPL only.
To cope with code duplication we could create tinycompress as a git 
submodule and educate alsa-lib build system to pull a tag and use that 
to compile the support for compress api.

Makes sense?

Alternatively, can't the android use case really use alsa-lib? I don't 
quite understand the problem except I'm guessing that it wants to 
statically link against tinycompress so it wants the dual license to 
avoid releasing the source code.

Re: [ALSA-UTILS][PATCH] Add support for cplay and crecord

[Jaroslav Kysela]

Dne 5.3.2015 v 13:37 Qais Yousef napsal(a):
> On 03/05/2015 08:52 AM, Takashi Iwai wrote:
>> At Thu, 5 Mar 2015 14:00:54 +0530,
>> Vinod Koul wrote:
>>> On Thu, Mar 05, 2015 at 08:43:18AM +0100, Jaroslav Kysela wrote:
>>>> Dne 5.3.2015 v 08:00 Vinod Koul napsal(a):
>>>>> On Wed, Mar 04, 2015 at 04:34:41PM +0000, Qais Yousef wrote:
>>>>>> On 03/04/2015 04:10 PM, Vinod Koul wrote:
>>>>>>> On Wed, Mar 04, 2015 at 03:36:00PM +0000, Qais Yousef wrote:
>>>>>>>> cplay and crecord use compress offload API to play and record compressed audio.
>>>>>>>>
>>>>>>>> They're based on cplay and crec from tinycompress library using LGPL license.
>>>>>>>>
>>>>>>>> For now cplay only supports playing mp3 files.
>>>>>>>>
>>>>>>>> Signed-off-by: Qais Yousef <qais.yousef@imgtec.com>
>>>>>>>> Cc: Takashi Iwai <tiwai@suse.de>
>>>>>>>> Cc: Vinod Koul <vinod.koul@intel.com>
>>>>>>>> Cc: Mark Brown <broonie@kernel.org>
>>>>>>>> ---
>>>>>>>> I renamed crec to crecord also to match aplay and arecord, hopefully
>>>>>>>> you don't mind Vinod.
>>>>>>> No thats fine..
>>>>>>>
>>>>>>>> This patch is dependent on my other patch that adds support for compress offload
>>>>>>>> to alsa-lib.
>>>>>>> And where is that, should have preceded this
>>>>>> Hmm not sure what went wrong. I resent it. Seems I have some emailer
>>>>>> issues as I had this problem before.
>>>>>> Hopefully you received it now.
>>>>>>
>>>>>>>> I needed to include <sound/compress_params.h> in cplay.c and crec.c
>>>>>>>> but I couldn't find an example of any C file which directly includes <sound/*.h>
>>>>>>>> The norm seems to be to just include <alsa/asoundlib.h>. Do I need to
>>>>>>>> redefine structs from <sound/compress_params.h> to newly added <alsa/compress.h>?
>>>>>>>> <alsa/pcm.h> seems to redefine structs from <sound/asound.h>.
>>>>>>> These are kernel headers and should be in your include path if you have
>>>>>>> those installed
>>>>>>>> I could only test cplay but have no means to test crecord at the moment.
>>>>>>>>
>>>>>>>>   Makefile.am       |   3 +
>>>>>>>>   configure.ac      |   6 +-
>>>>>>>>   cplay/Makefile.am |  14 ++
>>>>>>>>   cplay/cplay.c     | 294 +++++++++++++++++++++++++++++++++++
>>>>>>>>   cplay/crec.c      | 449 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>>>>>   cplay/tinymp3.h   |  72 +++++++++
>>>>>>>>   6 files changed, 837 insertions(+), 1 deletion(-)
>>>>>>>>   create mode 100644 cplay/Makefile.am
>>>>>>>>   create mode 100644 cplay/cplay.c
>>>>>>>>   create mode 100644 cplay/crec.c
>>>>>>>>   create mode 100644 cplay/tinymp3.h
>>>>>>> Okay here is where we need discussion on the future course. If we do this
>>>>>>> then we end up in two code bases, something I would not encourage!
>>>>>>>
>>>>>>> On the other hand if we add the make file changes to tinycompress or if
>>>>>>> required split this into two, lib and tools and then package lib part into
>>>>>>> alsa-lib and players into tools, that way we can have single code base. That
>>>>>>> was my intent behind ensuring that this is dual licensed.
>>>>>> I'm not sure I follow you completely here. You mean keep cplay and
>>>>>> crec in tinycompress with the dual licensing but only merge the lib
>>>>>> part (which my other patch does) into alsa-lib? For me having this
>>>>>> lib part into alsa-lib is the important bit. Moving crec and cplay
>>>>>> to alsa-utils was something I thought would be useful but maybe not.
>>>>> Not that
>>>>>
>>>>> Since alsa splits lib and tools, in order to take this into alsa-libs we
>>>>> need to split tinycompress, to something like lib and tool part.
>>>>>
>>>>> Then alsa-lib can import the lib part of tinycompress. Please note I am not
>>>>> saying we should copy or move code into alsa-lib.
>>>>> The reason for that is
>>>>> 1. copying code will cause more maintaince of same code in two places :(
>>>>> 2. moving into alsa-lib is not an option as existing users like android will
>>>>> suffer as they dont use alsa-lib
>>>>>
>>>>> So I think, while building and packaging alsa-library and tools we can
>>>>> import the tinycompress using LGPL license and use that to give complete
>>>>> library on Linux to users
>>>>>
>>>>> Takashi, can we get you blessing for this approach before we embark on this,
>>>>> or any other better ideas?
>>>> The problem is if the code is not duplicated, then the parts of the
>>>> alsa-lib binary will be dual-licenced. I don't think that it's the right
>>>> way.
>>>>
>>>> And if the code is duplicated, then patch authors for all next updates
>>>> in both libraries (alsa-lib, tinycompress) must be asked for permissions
>>>> to change code licence for the merge to the second library.
>>>>
>>>> I think that a plugin-style extension should be created here (so
>>>> tinycompress will be used at runtime as the dynamic library).
>>>>
>>>> compress API -> tinycompress plugin -> tinycompress .so functions
>>>>
>>>> This will allow us also to create another plugins in future.
>>> That does solve the issue for me as well. The intent is to provide
>>> compressed functionality within alsa-libs so asa plugin that can work very
>>> well...
>>>
>>> Any other thoughts... ?
>> Well, tinycompress itself is merely a thin layer covering the kernel
>> ABI.  So, writing a plugin infrastructure itself already achieves the
>> whole rewrite of tinycompress library.  What else remains as a plugin
>> content?
>>
>>
>> Takashi
> 
> OK reading a bit more about dual license what I understood is that it's 
> ok for alsa-lib to choose redistribute tinycompress as LGPL only.
> To cope with code duplication we could create tinycompress as a git 
> submodule and educate alsa-lib build system to pull a tag and use that 
> to compile the support for compress api.
> 
> Makes sense?

Thinking again about this and all suggested variants to use the
tinycompress code are not ideal. The alsa-lib is LGPL. Dot. I don't
think that we want to link (compile time linking) to any external code.

My .so plugin proposal is probably ok, but as Takashi said, it means
that the alsa-lib API code would be more bigger than the ioctl wrapper
code in tinycompress - the question is if it makes sense.

So I think that the best way is to fork the code and create compatible
APIs (headers) with the possible API change syncing.

				Thanks,
					Jaroslav

-- 
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project; Red Hat, Inc.

snd-aloop not working in linux-3.12.10

[Srinivasan S]

Dear Jaroslav

As this feature ie., snd-aloop designed by you,  could you please redirect to the respective links where my queries can be posted & get the solutions for the problem

As we are trying to establish GSM two way calls via stereo codec

We are planning to use loopback module (ie.,snd-aloop and alsaloop in ti sdk 7) to connect the sink/source and source/sink GSM and Codec. 

The below is the virtual devices created after configuring snd-aloop in the linux kernel 3.12.10

card 0, device 0
card 0, device 1

whatever am playing we are unable to record in the virtual device, but we are able to play & record with actual device

aplay -D hw:0,0,0 play.wav
arecord -D hw:0,1,0 record.wav or alsaloop -C hw:0,1 -P hw:0,0 -t 50000 # second terminal, latency 50ms

As per the logs below, am using the above commands to perform loopback, could you please let me know why am unable to perform the loopback with the below commands or please let me know am I missing any configurations, 

As this is feature is not working in ti sdk 7 (ie.,snd-aloop and alsaloop), 

Kindly requesting to try in your am335x-evm where it has tlv codec & verify this feature ie., snd-aloop & let me know as early as possible


logs :
======
root@am335x-evm:/# ls /dev/snd/   
by-path    controlC1  pcmC0D0p   pcmC0D1p   pcmC1D0p
controlC0  pcmC0D0c   pcmC0D1c   pcmC1D0c   timer
root@am335x-evm:/# cat /proc/asound/devices
  0: [ 0]   : control
 16: [ 0- 0]: digital audio playback
 17: [ 0- 1]: digital audio playback
 24: [ 0- 0]: digital audio capture
 25: [ 0- 1]: digital audio capture
 32: [ 1]   : control
 33:        : timer
 48: [ 1- 0]: digital audio playback
 56: [ 1- 0]: digital audio capture
root@am335x-evm:/# 

Loopback device
----------------
root@am335x-evm:/# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: Loopback [Loopback], device 0: Loopback PCM [Loopback PCM]
  Subdevices: 8/8
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
  Subdevice #2: subdevice #2
  Subdevice #3: subdevice #3
  Subdevice #4: subdevice #4
  Subdevice #5: subdevice #5
  Subdevice #6: subdevice #6
  Subdevice #7: subdevice #7
card 0: Loopback [Loopback], device 1: Loopback PCM [Loopback PCM]
  Subdevices: 8/8
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
  Subdevice #2: subdevice #2
  Subdevice #3: subdevice #3
  Subdevice #4: subdevice #4
  Subdevice #5: subdevice #5
  Subdevice #6: subdevice #6
  Subdevice #7: subdevice #7
card 1: UDA1345TS [TI UDA1345TS], device 0: UDA134x uda134x-hifi-0 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
root@am335x-evm:/# aplay -D hw:0,0,0 TangoForTajMusic11.wav 
Playing WAVE 'TangoForTajMusic11.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo



Actual device
-------------
root@am335x-evm:/# aplay -D hw:1,0,0 TangoForTajMusic11.wav                                                                                    
Playing WAVE 'TangoForTajMusic11.wav' : Signed 16 bit Li[ 2219.654309] DAVINCIIIIIIIIII UDA134XXXXX SYSCLK=12288000
ttle Endian, Rate 48000 Hz, Stereo
[ 2219.663776] DAVINCIIIIIIIIII UDA134XXXXX BCLK FREQQ=1536000
[ 2219.672880] DAVINCIIIIIIIIII UDA134XXXXX SYSCLK/BCLK_FREQ =8
[ 2219.678982] uda134x_hw_params CLOCKS uda134x_hw_params uda134x->sysclk: 12288000, params_rate(params):48000
[ 2219.689474] uda134x_hw_params FORMATS uda134x_hw_params dai_fmt: 16385, params_format:2
[ 2219.698095] uda134x_hw_params FORMATS uda134x_hw_params uda134x->sysclk / params_rate(params) 256
[ 2219.707644] UDA1345TSSSSSSSSSSSS SYSCLK / fs ratio is 256
[ 2219.713470] uda134x_hw_params dai_fmt: 16385, params_format:2
[ 2219.719639] UDA1345TSSSSSSSSSSSS FORMAT SND_SOC_DAIFMT_I2S
[ 2219.725716] ENTERED davinci_config_channel_size davinci_config_channel_size: tx_rotate = 4
[ 2219.734620] ENTERED davinci_config_channel_size davinci_config_channel_size: MASK= 65535
[ 2219.748324] uda134x_unnnnnnnnmuteeeeeeeeee uda134x_mute mute: 0
[ 2219.756522] davinci_mcasp_starttttttttttttttttttttt SNDRV_PCM_STREAM_PLAYBACK 


Kindly do the needful as early as possible
Awaiting for your replies,

Many Thanks in advance,

________________________________________
From: alsa-devel-bounces@alsa-project.org <alsa-devel-bounces@alsa-project.org> on behalf of Jaroslav Kysela <perex@perex.cz>
Sent: Thursday, March 5, 2015 7:09 PM
To: Qais Yousef; Takashi Iwai; Vinod Koul
Cc: alsa-devel@alsa-project.org; Mark Brown; Pierre-Louis Bossart
Subject: Re: [alsa-devel] [ALSA-UTILS][PATCH] Add support for cplay and crecord

Dne 5.3.2015 v 13:37 Qais Yousef napsal(a):
> On 03/05/2015 08:52 AM, Takashi Iwai wrote:
>> At Thu, 5 Mar 2015 14:00:54 +0530,
>> Vinod Koul wrote:
>>> On Thu, Mar 05, 2015 at 08:43:18AM +0100, Jaroslav Kysela wrote:
>>>> Dne 5.3.2015 v 08:00 Vinod Koul napsal(a):
>>>>> On Wed, Mar 04, 2015 at 04:34:41PM +0000, Qais Yousef wrote:
>>>>>> On 03/04/2015 04:10 PM, Vinod Koul wrote:
>>>>>>> On Wed, Mar 04, 2015 at 03:36:00PM +0000, Qais Yousef wrote:
>>>>>>>> cplay and crecord use compress offload API to play and record compressed audio.
>>>>>>>>
>>>>>>>> They're based on cplay and crec from tinycompress library using LGPL license.
>>>>>>>>
>>>>>>>> For now cplay only supports playing mp3 files.
>>>>>>>>
>>>>>>>> Signed-off-by: Qais Yousef <qais.yousef@imgtec.com>
>>>>>>>> Cc: Takashi Iwai <tiwai@suse.de>
>>>>>>>> Cc: Vinod Koul <vinod.koul@intel.com>
>>>>>>>> Cc: Mark Brown <broonie@kernel.org>
>>>>>>>> ---
>>>>>>>> I renamed crec to crecord also to match aplay and arecord, hopefully
>>>>>>>> you don't mind Vinod.
>>>>>>> No thats fine..
>>>>>>>
>>>>>>>> This patch is dependent on my other patch that adds support for compress offload
>>>>>>>> to alsa-lib.
>>>>>>> And where is that, should have preceded this
>>>>>> Hmm not sure what went wrong. I resent it. Seems I have some emailer
>>>>>> issues as I had this problem before.
>>>>>> Hopefully you received it now.
>>>>>>
>>>>>>>> I needed to include <sound/compress_params.h> in cplay.c and crec.c
>>>>>>>> but I couldn't find an example of any C file which directly includes <sound/*.h>
>>>>>>>> The norm seems to be to just include <alsa/asoundlib.h>. Do I need to
>>>>>>>> redefine structs from <sound/compress_params.h> to newly added <alsa/compress.h>?
>>>>>>>> <alsa/pcm.h> seems to redefine structs from <sound/asound.h>.
>>>>>>> These are kernel headers and should be in your include path if you have
>>>>>>> those installed
>>>>>>>> I could only test cplay but have no means to test crecord at the moment.
>>>>>>>>
>>>>>>>>   Makefile.am       |   3 +
>>>>>>>>   configure.ac      |   6 +-
>>>>>>>>   cplay/Makefile.am |  14 ++
>>>>>>>>   cplay/cplay.c     | 294 +++++++++++++++++++++++++++++++++++
>>>>>>>>   cplay/crec.c      | 449 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>>>>>   cplay/tinymp3.h   |  72 +++++++++
>>>>>>>>   6 files changed, 837 insertions(+), 1 deletion(-)
>>>>>>>>   create mode 100644 cplay/Makefile.am
>>>>>>>>   create mode 100644 cplay/cplay.c
>>>>>>>>   create mode 100644 cplay/crec.c
>>>>>>>>   create mode 100644 cplay/tinymp3.h
>>>>>>> Okay here is where we need discussion on the future course. If we do this
>>>>>>> then we end up in two code bases, something I would not encourage!
>>>>>>>
>>>>>>> On the other hand if we add the make file changes to tinycompress or if
>>>>>>> required split this into two, lib and tools and then package lib part into
>>>>>>> alsa-lib and players into tools, that way we can have single code base. That
>>>>>>> was my intent behind ensuring that this is dual licensed.
>>>>>> I'm not sure I follow you completely here. You mean keep cplay and
>>>>>> crec in tinycompress with the dual licensing but only merge the lib
>>>>>> part (which my other patch does) into alsa-lib? For me having this
>>>>>> lib part into alsa-lib is the important bit. Moving crec and cplay
>>>>>> to alsa-utils was something I thought would be useful but maybe not.
>>>>> Not that
>>>>>
>>>>> Since alsa splits lib and tools, in order to take this into alsa-libs we
>>>>> need to split tinycompress, to something like lib and tool part.
>>>>>
>>>>> Then alsa-lib can import the lib part of tinycompress. Please note I am not
>>>>> saying we should copy or move code into alsa-lib.
>>>>> The reason for that is
>>>>> 1. copying code will cause more maintaince of same code in two places :(
>>>>> 2. moving into alsa-lib is not an option as existing users like android will
>>>>> suffer as they dont use alsa-lib
>>>>>
>>>>> So I think, while building and packaging alsa-library and tools we can
>>>>> import the tinycompress using LGPL license and use that to give complete
>>>>> library on Linux to users
>>>>>
>>>>> Takashi, can we get you blessing for this approach before we embark on this,
>>>>> or any other better ideas?
>>>> The problem is if the code is not duplicated, then the parts of the
>>>> alsa-lib binary will be dual-licenced. I don't think that it's the right
>>>> way.
>>>>
>>>> And if the code is duplicated, then patch authors for all next updates
>>>> in both libraries (alsa-lib, tinycompress) must be asked for permissions
>>>> to change code licence for the merge to the second library.
>>>>
>>>> I think that a plugin-style extension should be created here (so
>>>> tinycompress will be used at runtime as the dynamic library).
>>>>
>>>> compress API -> tinycompress plugin -> tinycompress .so functions
>>>>
>>>> This will allow us also to create another plugins in future.
>>> That does solve the issue for me as well. The intent is to provide
>>> compressed functionality within alsa-libs so asa plugin that can work very
>>> well...
>>>
>>> Any other thoughts... ?
>> Well, tinycompress itself is merely a thin layer covering the kernel
>> ABI.  So, writing a plugin infrastructure itself already achieves the
>> whole rewrite of tinycompress library.  What else remains as a plugin
>> content?
>>
>>
>> Takashi
>
> OK reading a bit more about dual license what I understood is that it's
> ok for alsa-lib to choose redistribute tinycompress as LGPL only.
> To cope with code duplication we could create tinycompress as a git
> submodule and educate alsa-lib build system to pull a tag and use that
> to compile the support for compress api.
>
> Makes sense?

Thinking again about this and all suggested variants to use the
tinycompress code are not ideal. The alsa-lib is LGPL. Dot. I don't
think that we want to link (compile time linking) to any external code.

My .so plugin proposal is probably ok, but as Takashi said, it means
that the alsa-lib API code would be more bigger than the ioctl wrapper
code in tinycompress - the question is if it makes sense.

So I think that the best way is to fork the code and create compatible
APIs (headers) with the possible API change syncing.

                                Thanks,
                                        Jaroslav

--
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project; Red Hat, Inc.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: snd-aloop not working in linux-3.12.10

[Jaroslav Kysela]

Dne 5.3.2015 v 14:45 Srinivasan S napsal(a):
> Dear Jaroslav
> 
> As this feature ie., snd-aloop designed by you,  could you please redirect to the respective links where my queries can be posted & get the solutions for the problem

No idea. It looks like you are asking for a commercial support.
It may be a cache coherency issue or something else. The embedded/ARM
platforms might behave completely differently than x86 on which
this code was developed and tested.

				Jaroslav

> 
> As we are trying to establish GSM two way calls via stereo codec
> 
> We are planning to use loopback module (ie.,snd-aloop and alsaloop in ti sdk 7) to connect the sink/source and source/sink GSM and Codec. 
> 
> The below is the virtual devices created after configuring snd-aloop in the linux kernel 3.12.10
> 
> card 0, device 0
> card 0, device 1
> 
> whatever am playing we are unable to record in the virtual device, but we are able to play & record with actual device
> 
> aplay -D hw:0,0,0 play.wav
> arecord -D hw:0,1,0 record.wav or alsaloop -C hw:0,1 -P hw:0,0 -t 50000 # second terminal, latency 50ms
> 
> As per the logs below, am using the above commands to perform loopback, could you please let me know why am unable to perform the loopback with the below commands or please let me know am I missing any configurations, 
> 
> As this is feature is not working in ti sdk 7 (ie.,snd-aloop and alsaloop), 
> 
> Kindly requesting to try in your am335x-evm where it has tlv codec & verify this feature ie., snd-aloop & let me know as early as possible
> 
> 
> logs :
> ======
> root@am335x-evm:/# ls /dev/snd/   
> by-path    controlC1  pcmC0D0p   pcmC0D1p   pcmC1D0p
> controlC0  pcmC0D0c   pcmC0D1c   pcmC1D0c   timer
> root@am335x-evm:/# cat /proc/asound/devices
>   0: [ 0]   : control
>  16: [ 0- 0]: digital audio playback
>  17: [ 0- 1]: digital audio playback
>  24: [ 0- 0]: digital audio capture
>  25: [ 0- 1]: digital audio capture
>  32: [ 1]   : control
>  33:        : timer
>  48: [ 1- 0]: digital audio playback
>  56: [ 1- 0]: digital audio capture
> root@am335x-evm:/# 
> 
> Loopback device
> ----------------
> root@am335x-evm:/# aplay -l
> **** List of PLAYBACK Hardware Devices ****
> card 0: Loopback [Loopback], device 0: Loopback PCM [Loopback PCM]
>   Subdevices: 8/8
>   Subdevice #0: subdevice #0
>   Subdevice #1: subdevice #1
>   Subdevice #2: subdevice #2
>   Subdevice #3: subdevice #3
>   Subdevice #4: subdevice #4
>   Subdevice #5: subdevice #5
>   Subdevice #6: subdevice #6
>   Subdevice #7: subdevice #7
> card 0: Loopback [Loopback], device 1: Loopback PCM [Loopback PCM]
>   Subdevices: 8/8
>   Subdevice #0: subdevice #0
>   Subdevice #1: subdevice #1
>   Subdevice #2: subdevice #2
>   Subdevice #3: subdevice #3
>   Subdevice #4: subdevice #4
>   Subdevice #5: subdevice #5
>   Subdevice #6: subdevice #6
>   Subdevice #7: subdevice #7
> card 1: UDA1345TS [TI UDA1345TS], device 0: UDA134x uda134x-hifi-0 []
>   Subdevices: 1/1
>   Subdevice #0: subdevice #0
> root@am335x-evm:/# aplay -D hw:0,0,0 TangoForTajMusic11.wav 
> Playing WAVE 'TangoForTajMusic11.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
> 
> 
> 
> Actual device
> -------------
> root@am335x-evm:/# aplay -D hw:1,0,0 TangoForTajMusic11.wav                                                                                    
> Playing WAVE 'TangoForTajMusic11.wav' : Signed 16 bit Li[ 2219.654309] DAVINCIIIIIIIIII UDA134XXXXX SYSCLK=12288000
> ttle Endian, Rate 48000 Hz, Stereo
> [ 2219.663776] DAVINCIIIIIIIIII UDA134XXXXX BCLK FREQQ=1536000
> [ 2219.672880] DAVINCIIIIIIIIII UDA134XXXXX SYSCLK/BCLK_FREQ =8
> [ 2219.678982] uda134x_hw_params CLOCKS uda134x_hw_params uda134x->sysclk: 12288000, params_rate(params):48000
> [ 2219.689474] uda134x_hw_params FORMATS uda134x_hw_params dai_fmt: 16385, params_format:2
> [ 2219.698095] uda134x_hw_params FORMATS uda134x_hw_params uda134x->sysclk / params_rate(params) 256
> [ 2219.707644] UDA1345TSSSSSSSSSSSS SYSCLK / fs ratio is 256
> [ 2219.713470] uda134x_hw_params dai_fmt: 16385, params_format:2
> [ 2219.719639] UDA1345TSSSSSSSSSSSS FORMAT SND_SOC_DAIFMT_I2S
> [ 2219.725716] ENTERED davinci_config_channel_size davinci_config_channel_size: tx_rotate = 4
> [ 2219.734620] ENTERED davinci_config_channel_size davinci_config_channel_size: MASK= 65535
> [ 2219.748324] uda134x_unnnnnnnnmuteeeeeeeeee uda134x_mute mute: 0
> [ 2219.756522] davinci_mcasp_starttttttttttttttttttttt SNDRV_PCM_STREAM_PLAYBACK 
> 
> 
> Kindly do the needful as early as possible
> Awaiting for your replies,
> 
> Many Thanks in advance,


-- 
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project; Red Hat, Inc.

Re: snd-aloop not working in linux-3.12.10

[Srinivasan S]

Thanks for your replies,

I even tried in the below linux host machine first ie., ubuntu 12.04 prior trying in embedded board
Linux srinivasan-Latitude-3440 3.13.0-43-generic #72~precise1-Ubuntu SMP Tue Dec 9 12:14:18 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

am getting the below

> card 1, device 0
> card 1, device 1

aplay -D hw:1,0,0 TangoForTajMusic11.wav

arecord -D hw:1,1,0 record .wav

Still this is not working in the linux host machine

Could you please help me out in resolving this issue in host machine

Thanks in advance



________________________________________
From: Jaroslav Kysela <perex@perex.cz>
Sent: Thursday, March 5, 2015 7:43 PM
To: Srinivasan S
Cc: alsa-devel@alsa-project.org
Subject: Re: snd-aloop not working in linux-3.12.10

Dne 5.3.2015 v 14:45 Srinivasan S napsal(a):
> Dear Jaroslav
>
> As this feature ie., snd-aloop designed by you,  could you please redirect to the respective links where my queries can be posted & get the solutions for the problem

No idea. It looks like you are asking for a commercial support.
It may be a cache coherency issue or something else. The embedded/ARM
platforms might behave completely differently than x86 on which
this code was developed and tested.

                                Jaroslav

>
> As we are trying to establish GSM two way calls via stereo codec
>
> We are planning to use loopback module (ie.,snd-aloop and alsaloop in ti sdk 7) to connect the sink/source and source/sink GSM and Codec.
>
> The below is the virtual devices created after configuring snd-aloop in the linux kernel 3.12.10
>
> card 0, device 0
> card 0, device 1
>
> whatever am playing we are unable to record in the virtual device, but we are able to play & record with actual device
>
> aplay -D hw:0,0,0 play.wav
> arecord -D hw:0,1,0 record.wav or alsaloop -C hw:0,1 -P hw:0,0 -t 50000 # second terminal, latency 50ms
>
> As per the logs below, am using the above commands to perform loopback, could you please let me know why am unable to perform the loopback with the below commands or please let me know am I missing any configurations,
>
> As this is feature is not working in ti sdk 7 (ie.,snd-aloop and alsaloop),
>
> Kindly requesting to try in your am335x-evm where it has tlv codec & verify this feature ie., snd-aloop & let me know as early as possible
>
>
> logs :
> ======
> root@am335x-evm:/# ls /dev/snd/
> by-path    controlC1  pcmC0D0p   pcmC0D1p   pcmC1D0p
> controlC0  pcmC0D0c   pcmC0D1c   pcmC1D0c   timer
> root@am335x-evm:/# cat /proc/asound/devices
>   0: [ 0]   : control
>  16: [ 0- 0]: digital audio playback
>  17: [ 0- 1]: digital audio playback
>  24: [ 0- 0]: digital audio capture
>  25: [ 0- 1]: digital audio capture
>  32: [ 1]   : control
>  33:        : timer
>  48: [ 1- 0]: digital audio playback
>  56: [ 1- 0]: digital audio capture
> root@am335x-evm:/#
>
> Loopback device
> ----------------
> root@am335x-evm:/# aplay -l
> **** List of PLAYBACK Hardware Devices ****
> card 0: Loopback [Loopback], device 0: Loopback PCM [Loopback PCM]
>   Subdevices: 8/8
>   Subdevice #0: subdevice #0
>   Subdevice #1: subdevice #1
>   Subdevice #2: subdevice #2
>   Subdevice #3: subdevice #3
>   Subdevice #4: subdevice #4
>   Subdevice #5: subdevice #5
>   Subdevice #6: subdevice #6
>   Subdevice #7: subdevice #7
> card 0: Loopback [Loopback], device 1: Loopback PCM [Loopback PCM]
>   Subdevices: 8/8
>   Subdevice #0: subdevice #0
>   Subdevice #1: subdevice #1
>   Subdevice #2: subdevice #2
>   Subdevice #3: subdevice #3
>   Subdevice #4: subdevice #4
>   Subdevice #5: subdevice #5
>   Subdevice #6: subdevice #6
>   Subdevice #7: subdevice #7
> card 1: UDA1345TS [TI UDA1345TS], device 0: UDA134x uda134x-hifi-0 []
>   Subdevices: 1/1
>   Subdevice #0: subdevice #0
> root@am335x-evm:/# aplay -D hw:0,0,0 TangoForTajMusic11.wav
> Playing WAVE 'TangoForTajMusic11.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
>
>
>
> Actual device
> -------------
> root@am335x-evm:/# aplay -D hw:1,0,0 TangoForTajMusic11.wav
> Playing WAVE 'TangoForTajMusic11.wav' : Signed 16 bit Li[ 2219.654309] DAVINCIIIIIIIIII UDA134XXXXX SYSCLK=12288000
> ttle Endian, Rate 48000 Hz, Stereo
> [ 2219.663776] DAVINCIIIIIIIIII UDA134XXXXX BCLK FREQQ=1536000
> [ 2219.672880] DAVINCIIIIIIIIII UDA134XXXXX SYSCLK/BCLK_FREQ =8
> [ 2219.678982] uda134x_hw_params CLOCKS uda134x_hw_params uda134x->sysclk: 12288000, params_rate(params):48000
> [ 2219.689474] uda134x_hw_params FORMATS uda134x_hw_params dai_fmt: 16385, params_format:2
> [ 2219.698095] uda134x_hw_params FORMATS uda134x_hw_params uda134x->sysclk / params_rate(params) 256
> [ 2219.707644] UDA1345TSSSSSSSSSSSS SYSCLK / fs ratio is 256
> [ 2219.713470] uda134x_hw_params dai_fmt: 16385, params_format:2
> [ 2219.719639] UDA1345TSSSSSSSSSSSS FORMAT SND_SOC_DAIFMT_I2S
> [ 2219.725716] ENTERED davinci_config_channel_size davinci_config_channel_size: tx_rotate = 4
> [ 2219.734620] ENTERED davinci_config_channel_size davinci_config_channel_size: MASK= 65535
> [ 2219.748324] uda134x_unnnnnnnnmuteeeeeeeeee uda134x_mute mute: 0
> [ 2219.756522] davinci_mcasp_starttttttttttttttttttttt SNDRV_PCM_STREAM_PLAYBACK
>
>
> Kindly do the needful as early as possible
> Awaiting for your replies,
>
> Many Thanks in advance,


--
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project; Red Hat, Inc.

Re: snd-aloop not working in linux-3.12.10

[Jaroslav Kysela]

Dne 5.3.2015 v 17:42 Srinivasan S napsal(a):
> Thanks for your replies,
> 
> I even tried in the below linux host machine first ie., ubuntu 12.04 prior trying in embedded board
> Linux srinivasan-Latitude-3440 3.13.0-43-generic #72~precise1-Ubuntu SMP Tue Dec 9 12:14:18 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
> 
> am getting the below
> 
>> card 1, device 0
>> card 1, device 1
> 
> aplay -D hw:1,0,0 TangoForTajMusic11.wav
> 
> arecord -D hw:1,1,0 record .wav
> 
> Still this is not working in the linux host machine
> 
> Could you please help me out in resolving this issue in host machine

On my host, kernel 3.17.8-200.fc20.x86_64, loopback card is #3:

$ aplay -D plughw:3,0,0 /usr/share/sounds/alsa/Noise.wav
Playing WAVE '/usr/share/sounds/alsa/Noise.wav' : Signed 16 bit Little
Endian, Rate 48000 Hz, Mono
$ arecord -D plughw:3,1,0 -f dat -c 1 a.wav
Recording WAVE 'a.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono

As you see, the "capture" program must set the same parameters as the
sample provider.

This also works:

$ alsaloop -C hw:3,1 -P plughw:1 -t 50000

The "plughw:1" is the real sound hardware in this case (first device,
second soundcard #1). The aplay command is same as in the first example
with device "plughw:3,0,0". In this case, the alsaloop detects the PCM
stream paramter changes automatically using the control API:

$ amixer -c 3 controls
numid=2,iface=PCM,name='PCM Notify'
numid=1,iface=PCM,name='PCM Rate Shift 100000'
numid=3,iface=PCM,name='PCM Slave Active'
numid=6,iface=PCM,name='PCM Slave Channels'
numid=4,iface=PCM,name='PCM Slave Format'
numid=5,iface=PCM,name='PCM Slave Rate'
numid=8,iface=PCM,name='PCM Notify',subdevice=1
numid=7,iface=PCM,name='PCM Rate Shift 100000',subdevice=1
numid=9,iface=PCM,name='PCM Slave Active',subdevice=1


					Jaroslav


> 
> Thanks in advance
> 
> 
> 
> ________________________________________
> From: Jaroslav Kysela <perex@perex.cz>
> Sent: Thursday, March 5, 2015 7:43 PM
> To: Srinivasan S
> Cc: alsa-devel@alsa-project.org
> Subject: Re: snd-aloop not working in linux-3.12.10
> 
> Dne 5.3.2015 v 14:45 Srinivasan S napsal(a):
>> Dear Jaroslav
>>
>> As this feature ie., snd-aloop designed by you,  could you please redirect to the respective links where my queries can be posted & get the solutions for the problem
> 
> No idea. It looks like you are asking for a commercial support.
> It may be a cache coherency issue or something else. The embedded/ARM
> platforms might behave completely differently than x86 on which
> this code was developed and tested.
> 
>                                 Jaroslav
> 
>>
>> As we are trying to establish GSM two way calls via stereo codec
>>
>> We are planning to use loopback module (ie.,snd-aloop and alsaloop in ti sdk 7) to connect the sink/source and source/sink GSM and Codec.
>>
>> The below is the virtual devices created after configuring snd-aloop in the linux kernel 3.12.10
>>
>> card 0, device 0
>> card 0, device 1
>>
>> whatever am playing we are unable to record in the virtual device, but we are able to play & record with actual device
>>
>> aplay -D hw:0,0,0 play.wav
>> arecord -D hw:0,1,0 record.wav or alsaloop -C hw:0,1 -P hw:0,0 -t 50000 # second terminal, latency 50ms
>>
>> As per the logs below, am using the above commands to perform loopback, could you please let me know why am unable to perform the loopback with the below commands or please let me know am I missing any configurations,
>>
>> As this is feature is not working in ti sdk 7 (ie.,snd-aloop and alsaloop),
>>
>> Kindly requesting to try in your am335x-evm where it has tlv codec & verify this feature ie., snd-aloop & let me know as early as possible
>>
>>
>> logs :
>> ======
>> root@am335x-evm:/# ls /dev/snd/
>> by-path    controlC1  pcmC0D0p   pcmC0D1p   pcmC1D0p
>> controlC0  pcmC0D0c   pcmC0D1c   pcmC1D0c   timer
>> root@am335x-evm:/# cat /proc/asound/devices
>>   0: [ 0]   : control
>>  16: [ 0- 0]: digital audio playback
>>  17: [ 0- 1]: digital audio playback
>>  24: [ 0- 0]: digital audio capture
>>  25: [ 0- 1]: digital audio capture
>>  32: [ 1]   : control
>>  33:        : timer
>>  48: [ 1- 0]: digital audio playback
>>  56: [ 1- 0]: digital audio capture
>> root@am335x-evm:/#
>>
>> Loopback device
>> ----------------
>> root@am335x-evm:/# aplay -l
>> **** List of PLAYBACK Hardware Devices ****
>> card 0: Loopback [Loopback], device 0: Loopback PCM [Loopback PCM]
>>   Subdevices: 8/8
>>   Subdevice #0: subdevice #0
>>   Subdevice #1: subdevice #1
>>   Subdevice #2: subdevice #2
>>   Subdevice #3: subdevice #3
>>   Subdevice #4: subdevice #4
>>   Subdevice #5: subdevice #5
>>   Subdevice #6: subdevice #6
>>   Subdevice #7: subdevice #7
>> card 0: Loopback [Loopback], device 1: Loopback PCM [Loopback PCM]
>>   Subdevices: 8/8
>>   Subdevice #0: subdevice #0
>>   Subdevice #1: subdevice #1
>>   Subdevice #2: subdevice #2
>>   Subdevice #3: subdevice #3
>>   Subdevice #4: subdevice #4
>>   Subdevice #5: subdevice #5
>>   Subdevice #6: subdevice #6
>>   Subdevice #7: subdevice #7
>> card 1: UDA1345TS [TI UDA1345TS], device 0: UDA134x uda134x-hifi-0 []
>>   Subdevices: 1/1
>>   Subdevice #0: subdevice #0
>> root@am335x-evm:/# aplay -D hw:0,0,0 TangoForTajMusic11.wav
>> Playing WAVE 'TangoForTajMusic11.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
>>
>>
>>
>> Actual device
>> -------------
>> root@am335x-evm:/# aplay -D hw:1,0,0 TangoForTajMusic11.wav
>> Playing WAVE 'TangoForTajMusic11.wav' : Signed 16 bit Li[ 2219.654309] DAVINCIIIIIIIIII UDA134XXXXX SYSCLK=12288000
>> ttle Endian, Rate 48000 Hz, Stereo
>> [ 2219.663776] DAVINCIIIIIIIIII UDA134XXXXX BCLK FREQQ=1536000
>> [ 2219.672880] DAVINCIIIIIIIIII UDA134XXXXX SYSCLK/BCLK_FREQ =8
>> [ 2219.678982] uda134x_hw_params CLOCKS uda134x_hw_params uda134x->sysclk: 12288000, params_rate(params):48000
>> [ 2219.689474] uda134x_hw_params FORMATS uda134x_hw_params dai_fmt: 16385, params_format:2
>> [ 2219.698095] uda134x_hw_params FORMATS uda134x_hw_params uda134x->sysclk / params_rate(params) 256
>> [ 2219.707644] UDA1345TSSSSSSSSSSSS SYSCLK / fs ratio is 256
>> [ 2219.713470] uda134x_hw_params dai_fmt: 16385, params_format:2
>> [ 2219.719639] UDA1345TSSSSSSSSSSSS FORMAT SND_SOC_DAIFMT_I2S
>> [ 2219.725716] ENTERED davinci_config_channel_size davinci_config_channel_size: tx_rotate = 4
>> [ 2219.734620] ENTERED davinci_config_channel_size davinci_config_channel_size: MASK= 65535
>> [ 2219.748324] uda134x_unnnnnnnnmuteeeeeeeeee uda134x_mute mute: 0
>> [ 2219.756522] davinci_mcasp_starttttttttttttttttttttt SNDRV_PCM_STREAM_PLAYBACK
>>
>>
>> Kindly do the needful as early as possible
>> Awaiting for your replies,
>>
>> Many Thanks in advance,
> 
> 
> --
> Jaroslav Kysela <perex@perex.cz>
> Linux Kernel Sound Maintainer
> ALSA Project; Red Hat, Inc.
> 


-- 
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project; Red Hat, Inc.

Re: snd-aloop not working in linux-3.12.10

[Srinivasan S]

Once again many Thanks for the quick responses,

Could you please try  & let me know whether does it works viceversa ie., arecord on loopback card first & then aplay on the loopback card as shown below

$ arecord -D plughw:3,1,0 -f dat -c 1 a.wav
Recording WAVE 'a.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono

$ aplay -D plughw:3,0,0 a.wav
Playing WAVE '/usr/share/sounds/alsa/Noise.wav' : Signed 16 bit Little
Endian, Rate 48000 Hz, Mono

Awaiting for your replies,

Thanks in advance again.
Srinivasan S


________________________________________
From: Jaroslav Kysela <perex@perex.cz>
Sent: Friday, March 6, 2015 12:21 AM
To: Srinivasan S
Cc: alsa-devel@alsa-project.org
Subject: Re: snd-aloop not working in linux-3.12.10

Dne 5.3.2015 v 17:42 Srinivasan S napsal(a):
> Thanks for your replies,
>
> I even tried in the below linux host machine first ie., ubuntu 12.04 prior trying in embedded board
> Linux srinivasan-Latitude-3440 3.13.0-43-generic #72~precise1-Ubuntu SMP Tue Dec 9 12:14:18 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
>
> am getting the below
>
>> card 1, device 0
>> card 1, device 1
>
> aplay -D hw:1,0,0 TangoForTajMusic11.wav
>
> arecord -D hw:1,1,0 record .wav
>
> Still this is not working in the linux host machine
>
> Could you please help me out in resolving this issue in host machine

On my host, kernel 3.17.8-200.fc20.x86_64, loopback card is #3:

$ aplay -D plughw:3,0,0 /usr/share/sounds/alsa/Noise.wav
Playing WAVE '/usr/share/sounds/alsa/Noise.wav' : Signed 16 bit Little
Endian, Rate 48000 Hz, Mono
$ arecord -D plughw:3,1,0 -f dat -c 1 a.wav
Recording WAVE 'a.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono

As you see, the "capture" program must set the same parameters as the
sample provider.

This also works:

$ alsaloop -C hw:3,1 -P plughw:1 -t 50000

The "plughw:1" is the real sound hardware in this case (first device,
second soundcard #1). The aplay command is same as in the first example
with device "plughw:3,0,0". In this case, the alsaloop detects the PCM
stream paramter changes automatically using the control API:

$ amixer -c 3 controls
numid=2,iface=PCM,name='PCM Notify'
numid=1,iface=PCM,name='PCM Rate Shift 100000'
numid=3,iface=PCM,name='PCM Slave Active'
numid=6,iface=PCM,name='PCM Slave Channels'
numid=4,iface=PCM,name='PCM Slave Format'
numid=5,iface=PCM,name='PCM Slave Rate'
numid=8,iface=PCM,name='PCM Notify',subdevice=1
numid=7,iface=PCM,name='PCM Rate Shift 100000',subdevice=1
numid=9,iface=PCM,name='PCM Slave Active',subdevice=1


                                        Jaroslav


>
> Thanks in advance
>
>
>
> ________________________________________
> From: Jaroslav Kysela <perex@perex.cz>
> Sent: Thursday, March 5, 2015 7:43 PM
> To: Srinivasan S
> Cc: alsa-devel@alsa-project.org
> Subject: Re: snd-aloop not working in linux-3.12.10
>
> Dne 5.3.2015 v 14:45 Srinivasan S napsal(a):
>> Dear Jaroslav
>>
>> As this feature ie., snd-aloop designed by you,  could you please redirect to the respective links where my queries can be posted & get the solutions for the problem
>
> No idea. It looks like you are asking for a commercial support.
> It may be a cache coherency issue or something else. The embedded/ARM
> platforms might behave completely differently than x86 on which
> this code was developed and tested.
>
>                                 Jaroslav
>
>>
>> As we are trying to establish GSM two way calls via stereo codec
>>
>> We are planning to use loopback module (ie.,snd-aloop and alsaloop in ti sdk 7) to connect the sink/source and source/sink GSM and Codec.
>>
>> The below is the virtual devices created after configuring snd-aloop in the linux kernel 3.12.10
>>
>> card 0, device 0
>> card 0, device 1
>>
>> whatever am playing we are unable to record in the virtual device, but we are able to play & record with actual device
>>
>> aplay -D hw:0,0,0 play.wav
>> arecord -D hw:0,1,0 record.wav or alsaloop -C hw:0,1 -P hw:0,0 -t 50000 # second terminal, latency 50ms
>>
>> As per the logs below, am using the above commands to perform loopback, could you please let me know why am unable to perform the loopback with the below commands or please let me know am I missing any configurations,
>>
>> As this is feature is not working in ti sdk 7 (ie.,snd-aloop and alsaloop),
>>
>> Kindly requesting to try in your am335x-evm where it has tlv codec & verify this feature ie., snd-aloop & let me know as early as possible
>>
>>
>> logs :
>> ======
>> root@am335x-evm:/# ls /dev/snd/
>> by-path    controlC1  pcmC0D0p   pcmC0D1p   pcmC1D0p
>> controlC0  pcmC0D0c   pcmC0D1c   pcmC1D0c   timer
>> root@am335x-evm:/# cat /proc/asound/devices
>>   0: [ 0]   : control
>>  16: [ 0- 0]: digital audio playback
>>  17: [ 0- 1]: digital audio playback
>>  24: [ 0- 0]: digital audio capture
>>  25: [ 0- 1]: digital audio capture
>>  32: [ 1]   : control
>>  33:        : timer
>>  48: [ 1- 0]: digital audio playback
>>  56: [ 1- 0]: digital audio capture
>> root@am335x-evm:/#
>>
>> Loopback device
>> ----------------
>> root@am335x-evm:/# aplay -l
>> **** List of PLAYBACK Hardware Devices ****
>> card 0: Loopback [Loopback], device 0: Loopback PCM [Loopback PCM]
>>   Subdevices: 8/8
>>   Subdevice #0: subdevice #0
>>   Subdevice #1: subdevice #1
>>   Subdevice #2: subdevice #2
>>   Subdevice #3: subdevice #3
>>   Subdevice #4: subdevice #4
>>   Subdevice #5: subdevice #5
>>   Subdevice #6: subdevice #6
>>   Subdevice #7: subdevice #7
>> card 0: Loopback [Loopback], device 1: Loopback PCM [Loopback PCM]
>>   Subdevices: 8/8
>>   Subdevice #0: subdevice #0
>>   Subdevice #1: subdevice #1
>>   Subdevice #2: subdevice #2
>>   Subdevice #3: subdevice #3
>>   Subdevice #4: subdevice #4
>>   Subdevice #5: subdevice #5
>>   Subdevice #6: subdevice #6
>>   Subdevice #7: subdevice #7
>> card 1: UDA1345TS [TI UDA1345TS], device 0: UDA134x uda134x-hifi-0 []
>>   Subdevices: 1/1
>>   Subdevice #0: subdevice #0
>> root@am335x-evm:/# aplay -D hw:0,0,0 TangoForTajMusic11.wav
>> Playing WAVE 'TangoForTajMusic11.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
>>
>>
>>
>> Actual device
>> -------------
>> root@am335x-evm:/# aplay -D hw:1,0,0 TangoForTajMusic11.wav
>> Playing WAVE 'TangoForTajMusic11.wav' : Signed 16 bit Li[ 2219.654309] DAVINCIIIIIIIIII UDA134XXXXX SYSCLK=12288000
>> ttle Endian, Rate 48000 Hz, Stereo
>> [ 2219.663776] DAVINCIIIIIIIIII UDA134XXXXX BCLK FREQQ=1536000
>> [ 2219.672880] DAVINCIIIIIIIIII UDA134XXXXX SYSCLK/BCLK_FREQ =8
>> [ 2219.678982] uda134x_hw_params CLOCKS uda134x_hw_params uda134x->sysclk: 12288000, params_rate(params):48000
>> [ 2219.689474] uda134x_hw_params FORMATS uda134x_hw_params dai_fmt: 16385, params_format:2
>> [ 2219.698095] uda134x_hw_params FORMATS uda134x_hw_params uda134x->sysclk / params_rate(params) 256
>> [ 2219.707644] UDA1345TSSSSSSSSSSSS SYSCLK / fs ratio is 256
>> [ 2219.713470] uda134x_hw_params dai_fmt: 16385, params_format:2
>> [ 2219.719639] UDA1345TSSSSSSSSSSSS FORMAT SND_SOC_DAIFMT_I2S
>> [ 2219.725716] ENTERED davinci_config_channel_size davinci_config_channel_size: tx_rotate = 4
>> [ 2219.734620] ENTERED davinci_config_channel_size davinci_config_channel_size: MASK= 65535
>> [ 2219.748324] uda134x_unnnnnnnnmuteeeeeeeeee uda134x_mute mute: 0
>> [ 2219.756522] davinci_mcasp_starttttttttttttttttttttt SNDRV_PCM_STREAM_PLAYBACK
>>
>>
>> Kindly do the needful as early as possible
>> Awaiting for your replies,
>>
>> Many Thanks in advance,
>
>
> --
> Jaroslav Kysela <perex@perex.cz>
> Linux Kernel Sound Maintainer
> ALSA Project; Red Hat, Inc.
>


--
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project; Red Hat, Inc.

Re: snd-aloop not working in linux-3.12.10

[Takashi Iwai]

At Fri, 6 Mar 2015 10:35:52 +0000,
Srinivasan S wrote:
> 
> Once again many Thanks for the quick responses,
> 
> Could you please try  & let me know whether does it works viceversa ie., arecord on loopback card first & then aplay on the loopback card as shown below
> 
> $ arecord -D plughw:3,1,0 -f dat -c 1 a.wav
> Recording WAVE 'a.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono
> 
> $ aplay -D plughw:3,0,0 a.wav
> Playing WAVE '/usr/share/sounds/alsa/Noise.wav' : Signed 16 bit Little
> Endian, Rate 48000 Hz, Mono

FYI, the above works for me, but I tested with the much later kernel,
and on x86 box.  You should try the very same kernel on x86 box, too.
If it works, the problem must be architecture-specific, e.g. the
memory cache issue.


Takashi

Re: snd-aloop not working in linux-3.12.10

[Jaroslav Kysela]

Dne 6.3.2015 v 11:35 Srinivasan S napsal(a):
> Once again many Thanks for the quick responses,
> 
> Could you please try  & let me know whether does it works viceversa ie., arecord on loopback card first & then aplay on the loopback card as shown below
> 
> $ arecord -D plughw:3,1,0 -f dat -c 1 a.wav
> Recording WAVE 'a.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono
> 
> $ aplay -D plughw:3,0,0 a.wav
> Playing WAVE '/usr/share/sounds/alsa/Noise.wav' : Signed 16 bit Little
> Endian, Rate 48000 Hz, Mono
> 
> Awaiting for your replies,

I'm not sure, if you understand the purpose of the loopback card. It
just passes the data from one playback device to another capture device
so it returns them to the userspace. So you need to have an input
(source) to be loopbacked. You're probably trying to loopback the zero
(silence) samples which are provided when the source is not available
from the loopback card.

You cannot do (simple notation):

arecord Loopback,1 | aplay Loopback,0

it's endless silence loop, but you can do (both commands should be
executed at same time):

aplay Loopback,0 <some_wav_file_with_real_content>
arecord Loopback,1 <loopbacked_result_stored_to_wav>

					Jaroslav

> 
> Thanks in advance again.
> Srinivasan S
> 
> 
> ________________________________________
> From: Jaroslav Kysela <perex@perex.cz>
> Sent: Friday, March 6, 2015 12:21 AM
> To: Srinivasan S
> Cc: alsa-devel@alsa-project.org
> Subject: Re: snd-aloop not working in linux-3.12.10
> 
> Dne 5.3.2015 v 17:42 Srinivasan S napsal(a):
>> Thanks for your replies,
>>
>> I even tried in the below linux host machine first ie., ubuntu 12.04 prior trying in embedded board
>> Linux srinivasan-Latitude-3440 3.13.0-43-generic #72~precise1-Ubuntu SMP Tue Dec 9 12:14:18 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
>>
>> am getting the below
>>
>>> card 1, device 0
>>> card 1, device 1
>>
>> aplay -D hw:1,0,0 TangoForTajMusic11.wav
>>
>> arecord -D hw:1,1,0 record .wav
>>
>> Still this is not working in the linux host machine
>>
>> Could you please help me out in resolving this issue in host machine
> 
> On my host, kernel 3.17.8-200.fc20.x86_64, loopback card is #3:
> 
> $ aplay -D plughw:3,0,0 /usr/share/sounds/alsa/Noise.wav
> Playing WAVE '/usr/share/sounds/alsa/Noise.wav' : Signed 16 bit Little
> Endian, Rate 48000 Hz, Mono
> $ arecord -D plughw:3,1,0 -f dat -c 1 a.wav
> Recording WAVE 'a.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono
> 
> As you see, the "capture" program must set the same parameters as the
> sample provider.
> 
> This also works:
> 
> $ alsaloop -C hw:3,1 -P plughw:1 -t 50000
> 
> The "plughw:1" is the real sound hardware in this case (first device,
> second soundcard #1). The aplay command is same as in the first example
> with device "plughw:3,0,0". In this case, the alsaloop detects the PCM
> stream paramter changes automatically using the control API:
> 
> $ amixer -c 3 controls
> numid=2,iface=PCM,name='PCM Notify'
> numid=1,iface=PCM,name='PCM Rate Shift 100000'
> numid=3,iface=PCM,name='PCM Slave Active'
> numid=6,iface=PCM,name='PCM Slave Channels'
> numid=4,iface=PCM,name='PCM Slave Format'
> numid=5,iface=PCM,name='PCM Slave Rate'
> numid=8,iface=PCM,name='PCM Notify',subdevice=1
> numid=7,iface=PCM,name='PCM Rate Shift 100000',subdevice=1
> numid=9,iface=PCM,name='PCM Slave Active',subdevice=1
> 
> 
>                                         Jaroslav
> 
> 
>>
>> Thanks in advance
>>
>>
>>
>> ________________________________________
>> From: Jaroslav Kysela <perex@perex.cz>
>> Sent: Thursday, March 5, 2015 7:43 PM
>> To: Srinivasan S
>> Cc: alsa-devel@alsa-project.org
>> Subject: Re: snd-aloop not working in linux-3.12.10
>>
>> Dne 5.3.2015 v 14:45 Srinivasan S napsal(a):
>>> Dear Jaroslav
>>>
>>> As this feature ie., snd-aloop designed by you,  could you please redirect to the respective links where my queries can be posted & get the solutions for the problem
>>
>> No idea. It looks like you are asking for a commercial support.
>> It may be a cache coherency issue or something else. The embedded/ARM
>> platforms might behave completely differently than x86 on which
>> this code was developed and tested.
>>
>>                                 Jaroslav
>>
>>>
>>> As we are trying to establish GSM two way calls via stereo codec
>>>
>>> We are planning to use loopback module (ie.,snd-aloop and alsaloop in ti sdk 7) to connect the sink/source and source/sink GSM and Codec.
>>>
>>> The below is the virtual devices created after configuring snd-aloop in the linux kernel 3.12.10
>>>
>>> card 0, device 0
>>> card 0, device 1
>>>
>>> whatever am playing we are unable to record in the virtual device, but we are able to play & record with actual device
>>>
>>> aplay -D hw:0,0,0 play.wav
>>> arecord -D hw:0,1,0 record.wav or alsaloop -C hw:0,1 -P hw:0,0 -t 50000 # second terminal, latency 50ms
>>>
>>> As per the logs below, am using the above commands to perform loopback, could you please let me know why am unable to perform the loopback with the below commands or please let me know am I missing any configurations,
>>>
>>> As this is feature is not working in ti sdk 7 (ie.,snd-aloop and alsaloop),
>>>
>>> Kindly requesting to try in your am335x-evm where it has tlv codec & verify this feature ie., snd-aloop & let me know as early as possible
>>>
>>>
>>> logs :
>>> ======
>>> root@am335x-evm:/# ls /dev/snd/
>>> by-path    controlC1  pcmC0D0p   pcmC0D1p   pcmC1D0p
>>> controlC0  pcmC0D0c   pcmC0D1c   pcmC1D0c   timer
>>> root@am335x-evm:/# cat /proc/asound/devices
>>>   0: [ 0]   : control
>>>  16: [ 0- 0]: digital audio playback
>>>  17: [ 0- 1]: digital audio playback
>>>  24: [ 0- 0]: digital audio capture
>>>  25: [ 0- 1]: digital audio capture
>>>  32: [ 1]   : control
>>>  33:        : timer
>>>  48: [ 1- 0]: digital audio playback
>>>  56: [ 1- 0]: digital audio capture
>>> root@am335x-evm:/#
>>>
>>> Loopback device
>>> ----------------
>>> root@am335x-evm:/# aplay -l
>>> **** List of PLAYBACK Hardware Devices ****
>>> card 0: Loopback [Loopback], device 0: Loopback PCM [Loopback PCM]
>>>   Subdevices: 8/8
>>>   Subdevice #0: subdevice #0
>>>   Subdevice #1: subdevice #1
>>>   Subdevice #2: subdevice #2
>>>   Subdevice #3: subdevice #3
>>>   Subdevice #4: subdevice #4
>>>   Subdevice #5: subdevice #5
>>>   Subdevice #6: subdevice #6
>>>   Subdevice #7: subdevice #7
>>> card 0: Loopback [Loopback], device 1: Loopback PCM [Loopback PCM]
>>>   Subdevices: 8/8
>>>   Subdevice #0: subdevice #0
>>>   Subdevice #1: subdevice #1
>>>   Subdevice #2: subdevice #2
>>>   Subdevice #3: subdevice #3
>>>   Subdevice #4: subdevice #4
>>>   Subdevice #5: subdevice #5
>>>   Subdevice #6: subdevice #6
>>>   Subdevice #7: subdevice #7
>>> card 1: UDA1345TS [TI UDA1345TS], device 0: UDA134x uda134x-hifi-0 []
>>>   Subdevices: 1/1
>>>   Subdevice #0: subdevice #0
>>> root@am335x-evm:/# aplay -D hw:0,0,0 TangoForTajMusic11.wav
>>> Playing WAVE 'TangoForTajMusic11.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
>>>
>>>
>>>
>>> Actual device
>>> -------------
>>> root@am335x-evm:/# aplay -D hw:1,0,0 TangoForTajMusic11.wav
>>> Playing WAVE 'TangoForTajMusic11.wav' : Signed 16 bit Li[ 2219.654309] DAVINCIIIIIIIIII UDA134XXXXX SYSCLK=12288000
>>> ttle Endian, Rate 48000 Hz, Stereo
>>> [ 2219.663776] DAVINCIIIIIIIIII UDA134XXXXX BCLK FREQQ=1536000
>>> [ 2219.672880] DAVINCIIIIIIIIII UDA134XXXXX SYSCLK/BCLK_FREQ =8
>>> [ 2219.678982] uda134x_hw_params CLOCKS uda134x_hw_params uda134x->sysclk: 12288000, params_rate(params):48000
>>> [ 2219.689474] uda134x_hw_params FORMATS uda134x_hw_params dai_fmt: 16385, params_format:2
>>> [ 2219.698095] uda134x_hw_params FORMATS uda134x_hw_params uda134x->sysclk / params_rate(params) 256
>>> [ 2219.707644] UDA1345TSSSSSSSSSSSS SYSCLK / fs ratio is 256
>>> [ 2219.713470] uda134x_hw_params dai_fmt: 16385, params_format:2
>>> [ 2219.719639] UDA1345TSSSSSSSSSSSS FORMAT SND_SOC_DAIFMT_I2S
>>> [ 2219.725716] ENTERED davinci_config_channel_size davinci_config_channel_size: tx_rotate = 4
>>> [ 2219.734620] ENTERED davinci_config_channel_size davinci_config_channel_size: MASK= 65535
>>> [ 2219.748324] uda134x_unnnnnnnnmuteeeeeeeeee uda134x_mute mute: 0
>>> [ 2219.756522] davinci_mcasp_starttttttttttttttttttttt SNDRV_PCM_STREAM_PLAYBACK
>>>
>>>
>>> Kindly do the needful as early as possible
>>> Awaiting for your replies,
>>>
>>> Many Thanks in advance,
>>
>>
>> --
>> Jaroslav Kysela <perex@perex.cz>
>> Linux Kernel Sound Maintainer
>> ALSA Project; Red Hat, Inc.
>>
> 
> 
> --
> Jaroslav Kysela <perex@perex.cz>
> Linux Kernel Sound Maintainer
> ALSA Project; Red Hat, Inc.
> 


-- 
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project; Red Hat, Inc.

Re: snd-aloop not working in linux-3.12.10

[Srinivasan S]

Once again Many Thanks a lot Jaroslav, and would appreciate a lot

Now am very clear w.r.t loopback card 

Basically I need two sound card devices using loopback. One is a GSM modem with a sink/source and the other is a audio codec, Using loopback module to connect the sink/source and source/sink GSM and Codec.

Could you please clarify the following points w.r.t loopback card(as am new to Alsa, Extremely sorry if this doubts seems to be silly for you)

1) As per the link http://alsa.opensrc.org/Jack_and_Loopback_device_as_Alsa-to-Jack_bridge

In the section, The Jack Bridge, ie.,Creating permanent Jack clients using alsa_in and alsa_out

Again am little bit confused in the link it is mentioned that

ie., Since we used subdevice 0,0 for playback and subdevice 0,1 for capture, 
I didn't understand that how the signal will be available in subdevice 1,0, which alsa_in listens to. The "cloop" client we created can now be connected to the jack system output ports and o miracle, you will hear your ALSA app :)

Could you please help me out in understanding 

# capture client
alsa_in -j cloop -dcloop

# playback client
alsa_out -j ploop -dploop 

ie., Is it possible to record using alsa_in & is it possible to playback the same recorded data using alsa_out independently?? or does it has any interdependencies on the loopback card as we discussed earlier (ie., for example in your case loopbackcard hw:3,0 (playback) & loopbackcard hw:3,1 (capture) )

2)Regarding w.r.t alsaloop
aplay -D plughw:1,0 <your_wav_file>
alsaloop -C hw:1,1 -P hw:0,0 -t 50000	

i) Could you please clarify ie., alsaloop does this performs the same as one playback device to another capture device
so it returns them to the userspace. ie., after aplay only alsaloop can be used or what?? 

ii) Could you please clarify ,inorder to use alsaloop is it mandatory to have amixer controls,
I didn't understand as what you said that is  alsaloop detects the PCM
stream paramter changes automatically using the control API ie., amixer -c 3 controls


Kindly do the needful as early as possible

Awaiting for your replies

Once again Many Thanks a lot for your prompt support w.r.t snd-aloop

________________________________________
From: Jaroslav Kysela <perex@perex.cz>
Sent: Friday, March 6, 2015 4:58 PM
To: Srinivasan S
Cc: alsa-devel@alsa-project.org
Subject: Re: snd-aloop not working in linux-3.12.10

Dne 6.3.2015 v 11:35 Srinivasan S napsal(a):
> Once again many Thanks for the quick responses,
>
> Could you please try  & let me know whether does it works viceversa ie., arecord on loopback card first & then aplay on the loopback card as shown below
>
> $ arecord -D plughw:3,1,0 -f dat -c 1 a.wav
> Recording WAVE 'a.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono
>
> $ aplay -D plughw:3,0,0 a.wav
> Playing WAVE '/usr/share/sounds/alsa/Noise.wav' : Signed 16 bit Little
> Endian, Rate 48000 Hz, Mono
>
> Awaiting for your replies,

I'm not sure, if you understand the purpose of the loopback card. It
just passes the data from one playback device to another capture device
so it returns them to the userspace. So you need to have an input
(source) to be loopbacked. You're probably trying to loopback the zero
(silence) samples which are provided when the source is not available
from the loopback card.

You cannot do (simple notation):

arecord Loopback,1 | aplay Loopback,0

it's endless silence loop, but you can do (both commands should be
executed at same time):

aplay Loopback,0 <some_wav_file_with_real_content>
arecord Loopback,1 <loopbacked_result_stored_to_wav>

                                        Jaroslav

>
> Thanks in advance again.
> Srinivasan S
>
>
> ________________________________________
> From: Jaroslav Kysela <perex@perex.cz>
> Sent: Friday, March 6, 2015 12:21 AM
> To: Srinivasan S
> Cc: alsa-devel@alsa-project.org
> Subject: Re: snd-aloop not working in linux-3.12.10
>
> Dne 5.3.2015 v 17:42 Srinivasan S napsal(a):
>> Thanks for your replies,
>>
>> I even tried in the below linux host machine first ie., ubuntu 12.04 prior trying in embedded board
>> Linux srinivasan-Latitude-3440 3.13.0-43-generic #72~precise1-Ubuntu SMP Tue Dec 9 12:14:18 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
>>
>> am getting the below
>>
>>> card 1, device 0
>>> card 1, device 1
>>
>> aplay -D hw:1,0,0 TangoForTajMusic11.wav
>>
>> arecord -D hw:1,1,0 record .wav
>>
>> Still this is not working in the linux host machine
>>
>> Could you please help me out in resolving this issue in host machine
>
> On my host, kernel 3.17.8-200.fc20.x86_64, loopback card is #3:
>
> $ aplay -D plughw:3,0,0 /usr/share/sounds/alsa/Noise.wav
> Playing WAVE '/usr/share/sounds/alsa/Noise.wav' : Signed 16 bit Little
> Endian, Rate 48000 Hz, Mono
> $ arecord -D plughw:3,1,0 -f dat -c 1 a.wav
> Recording WAVE 'a.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono
>
> As you see, the "capture" program must set the same parameters as the
> sample provider.
>
> This also works:
>
> $ alsaloop -C hw:3,1 -P plughw:1 -t 50000
>
> The "plughw:1" is the real sound hardware in this case (first device,
> second soundcard #1). The aplay command is same as in the first example
> with device "plughw:3,0,0". In this case, the alsaloop detects the PCM
> stream paramter changes automatically using the control API:
>
> $ amixer -c 3 controls
> numid=2,iface=PCM,name='PCM Notify'
> numid=1,iface=PCM,name='PCM Rate Shift 100000'
> numid=3,iface=PCM,name='PCM Slave Active'
> numid=6,iface=PCM,name='PCM Slave Channels'
> numid=4,iface=PCM,name='PCM Slave Format'
> numid=5,iface=PCM,name='PCM Slave Rate'
> numid=8,iface=PCM,name='PCM Notify',subdevice=1
> numid=7,iface=PCM,name='PCM Rate Shift 100000',subdevice=1
> numid=9,iface=PCM,name='PCM Slave Active',subdevice=1
>
>
>                                         Jaroslav
>
>
>>
>> Thanks in advance
>>
>>
>>
>> ________________________________________
>> From: Jaroslav Kysela <perex@perex.cz>
>> Sent: Thursday, March 5, 2015 7:43 PM
>> To: Srinivasan S
>> Cc: alsa-devel@alsa-project.org
>> Subject: Re: snd-aloop not working in linux-3.12.10
>>
>> Dne 5.3.2015 v 14:45 Srinivasan S napsal(a):
>>> Dear Jaroslav
>>>
>>> As this feature ie., snd-aloop designed by you,  could you please redirect to the respective links where my queries can be posted & get the solutions for the problem
>>
>> No idea. It looks like you are asking for a commercial support.
>> It may be a cache coherency issue or something else. The embedded/ARM
>> platforms might behave completely differently than x86 on which
>> this code was developed and tested.
>>
>>                                 Jaroslav
>>
>>>
>>> As we are trying to establish GSM two way calls via stereo codec
>>>
>>> We are planning to use loopback module (ie.,snd-aloop and alsaloop in ti sdk 7) to connect the sink/source and source/sink GSM and Codec.
>>>
>>> The below is the virtual devices created after configuring snd-aloop in the linux kernel 3.12.10
>>>
>>> card 0, device 0
>>> card 0, device 1
>>>
>>> whatever am playing we are unable to record in the virtual device, but we are able to play & record with actual device
>>>
>>> aplay -D hw:0,0,0 play.wav
>>> arecord -D hw:0,1,0 record.wav or alsaloop -C hw:0,1 -P hw:0,0 -t 50000 # second terminal, latency 50ms
>>>
>>> As per the logs below, am using the above commands to perform loopback, could you please let me know why am unable to perform the loopback with the below commands or please let me know am I missing any configurations,
>>>
>>> As this is feature is not working in ti sdk 7 (ie.,snd-aloop and alsaloop),
>>>
>>> Kindly requesting to try in your am335x-evm where it has tlv codec & verify this feature ie., snd-aloop & let me know as early as possible
>>>
>>>
>>> logs :
>>> ======
>>> root@am335x-evm:/# ls /dev/snd/
>>> by-path    controlC1  pcmC0D0p   pcmC0D1p   pcmC1D0p
>>> controlC0  pcmC0D0c   pcmC0D1c   pcmC1D0c   timer
>>> root@am335x-evm:/# cat /proc/asound/devices
>>>   0: [ 0]   : control
>>>  16: [ 0- 0]: digital audio playback
>>>  17: [ 0- 1]: digital audio playback
>>>  24: [ 0- 0]: digital audio capture
>>>  25: [ 0- 1]: digital audio capture
>>>  32: [ 1]   : control
>>>  33:        : timer
>>>  48: [ 1- 0]: digital audio playback
>>>  56: [ 1- 0]: digital audio capture
>>> root@am335x-evm:/#
>>>
>>> Loopback device
>>> ----------------
>>> root@am335x-evm:/# aplay -l
>>> **** List of PLAYBACK Hardware Devices ****
>>> card 0: Loopback [Loopback], device 0: Loopback PCM [Loopback PCM]
>>>   Subdevices: 8/8
>>>   Subdevice #0: subdevice #0
>>>   Subdevice #1: subdevice #1
>>>   Subdevice #2: subdevice #2
>>>   Subdevice #3: subdevice #3
>>>   Subdevice #4: subdevice #4
>>>   Subdevice #5: subdevice #5
>>>   Subdevice #6: subdevice #6
>>>   Subdevice #7: subdevice #7
>>> card 0: Loopback [Loopback], device 1: Loopback PCM [Loopback PCM]
>>>   Subdevices: 8/8
>>>   Subdevice #0: subdevice #0
>>>   Subdevice #1: subdevice #1
>>>   Subdevice #2: subdevice #2
>>>   Subdevice #3: subdevice #3
>>>   Subdevice #4: subdevice #4
>>>   Subdevice #5: subdevice #5
>>>   Subdevice #6: subdevice #6
>>>   Subdevice #7: subdevice #7
>>> card 1: UDA1345TS [TI UDA1345TS], device 0: UDA134x uda134x-hifi-0 []
>>>   Subdevices: 1/1
>>>   Subdevice #0: subdevice #0
>>> root@am335x-evm:/# aplay -D hw:0,0,0 TangoForTajMusic11.wav
>>> Playing WAVE 'TangoForTajMusic11.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
>>>
>>>
>>>
>>> Actual device
>>> -------------
>>> root@am335x-evm:/# aplay -D hw:1,0,0 TangoForTajMusic11.wav
>>> Playing WAVE 'TangoForTajMusic11.wav' : Signed 16 bit Li[ 2219.654309] DAVINCIIIIIIIIII UDA134XXXXX SYSCLK=12288000
>>> ttle Endian, Rate 48000 Hz, Stereo
>>> [ 2219.663776] DAVINCIIIIIIIIII UDA134XXXXX BCLK FREQQ=1536000
>>> [ 2219.672880] DAVINCIIIIIIIIII UDA134XXXXX SYSCLK/BCLK_FREQ =8
>>> [ 2219.678982] uda134x_hw_params CLOCKS uda134x_hw_params uda134x->sysclk: 12288000, params_rate(params):48000
>>> [ 2219.689474] uda134x_hw_params FORMATS uda134x_hw_params dai_fmt: 16385, params_format:2
>>> [ 2219.698095] uda134x_hw_params FORMATS uda134x_hw_params uda134x->sysclk / params_rate(params) 256
>>> [ 2219.707644] UDA1345TSSSSSSSSSSSS SYSCLK / fs ratio is 256
>>> [ 2219.713470] uda134x_hw_params dai_fmt: 16385, params_format:2
>>> [ 2219.719639] UDA1345TSSSSSSSSSSSS FORMAT SND_SOC_DAIFMT_I2S
>>> [ 2219.725716] ENTERED davinci_config_channel_size davinci_config_channel_size: tx_rotate = 4
>>> [ 2219.734620] ENTERED davinci_config_channel_size davinci_config_channel_size: MASK= 65535
>>> [ 2219.748324] uda134x_unnnnnnnnmuteeeeeeeeee uda134x_mute mute: 0
>>> [ 2219.756522] davinci_mcasp_starttttttttttttttttttttt SNDRV_PCM_STREAM_PLAYBACK
>>>
>>>
>>> Kindly do the needful as early as possible
>>> Awaiting for your replies,
>>>
>>> Many Thanks in advance,
>>
>>
>> --
>> Jaroslav Kysela <perex@perex.cz>
>> Linux Kernel Sound Maintainer
>> ALSA Project; Red Hat, Inc.
>>
>
>
> --
> Jaroslav Kysela <perex@perex.cz>
> Linux Kernel Sound Maintainer
> ALSA Project; Red Hat, Inc.
>


--
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project; Red Hat, Inc.

Re: snd-aloop not working in linux-3.12.10

[Srinivasan S]

Dear Jaroslav,

Very Good Morning!

Could you please kindly help me in clarifying my inline doubts, as I am pretty new to linux audio particularly ALSA Framework as I was involved only in intial codec bringup using aplay & arecord utilities , as I was having some trouble getting a grasp on it all,

Once the inline doubts are calrified, I can plan my design accordingly

And you really appreciate your prompt replies for my earlier two queries

Kindly do the needful as early possible

Awaiting for your replies,

Many Many Thanks in advance again,

________________________________________
From: alsa-devel-bounces@alsa-project.org <alsa-devel-bounces@alsa-project.org> on behalf of Srinivasan S <srinivasan.s@tataelxsi.co.in>
Sent: Friday, March 6, 2015 11:13 PM
To: Jaroslav Kysela
Cc: alsa-devel@alsa-project.org
Subject: Re: [alsa-devel] snd-aloop not working in linux-3.12.10

Once again Many Thanks a lot Jaroslav, and would appreciate a lot

Now am very clear w.r.t loopback card

Basically I need two sound card devices using loopback. One is a GSM modem with a sink/source and the other is a audio codec, Using loopback module to connect the sink/source and source/sink GSM and Codec.

Could you please clarify the following points w.r.t loopback card(as am new to Alsa, Extremely sorry if this doubts seems to be silly for you)

1) As per the link http://alsa.opensrc.org/Jack_and_Loopback_device_as_Alsa-to-Jack_bridge

In the section, The Jack Bridge, ie.,Creating permanent Jack clients using alsa_in and alsa_out

Again am little bit confused in the link it is mentioned that

ie., Since we used subdevice 0,0 for playback and subdevice 0,1 for capture,
I didn't understand that how the signal will be available in subdevice 1,0, which alsa_in listens to. The "cloop" client we created can now be connected to the jack system output ports and o miracle, you will hear your ALSA app :)

Could you please help me out in understanding

# capture client
alsa_in -j cloop -dcloop

# playback client
alsa_out -j ploop -dploop

ie., Is it possible to record using alsa_in & is it possible to playback the same recorded data using alsa_out independently?? or does it has any interdependencies on the loopback card as we discussed earlier (ie., for example in your case loopbackcard hw:3,0 (playback) & loopbackcard hw:3,1 (capture) )

2)Regarding w.r.t alsaloop
aplay -D plughw:1,0 <your_wav_file>
alsaloop -C hw:1,1 -P hw:0,0 -t 50000

i) Could you please clarify ie., alsaloop does this performs the same as one playback device to another capture device
so it returns them to the userspace. ie., after aplay only alsaloop can be used or what??

ii) Could you please clarify ,inorder to use alsaloop is it mandatory to have amixer controls,
I didn't understand as what you said that is  alsaloop detects the PCM
stream paramter changes automatically using the control API ie., amixer -c 3 controls


Kindly do the needful as early as possible

Awaiting for your replies

Once again Many Thanks a lot for your prompt support w.r.t snd-aloop

________________________________________
From: Jaroslav Kysela <perex@perex.cz>
Sent: Friday, March 6, 2015 4:58 PM
To: Srinivasan S
Cc: alsa-devel@alsa-project.org
Subject: Re: snd-aloop not working in linux-3.12.10

Dne 6.3.2015 v 11:35 Srinivasan S napsal(a):
> Once again many Thanks for the quick responses,
>
> Could you please try  & let me know whether does it works viceversa ie., arecord on loopback card first & then aplay on the loopback card as shown below
>
> $ arecord -D plughw:3,1,0 -f dat -c 1 a.wav
> Recording WAVE 'a.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono
>
> $ aplay -D plughw:3,0,0 a.wav
> Playing WAVE '/usr/share/sounds/alsa/Noise.wav' : Signed 16 bit Little
> Endian, Rate 48000 Hz, Mono
>
> Awaiting for your replies,

I'm not sure, if you understand the purpose of the loopback card. It
just passes the data from one playback device to another capture device
so it returns them to the userspace. So you need to have an input
(source) to be loopbacked. You're probably trying to loopback the zero
(silence) samples which are provided when the source is not available
from the loopback card.

You cannot do (simple notation):

arecord Loopback,1 | aplay Loopback,0

it's endless silence loop, but you can do (both commands should be
executed at same time):

aplay Loopback,0 <some_wav_file_with_real_content>
arecord Loopback,1 <loopbacked_result_stored_to_wav>

                                        Jaroslav

>
> Thanks in advance again.
> Srinivasan S
>
>
> ________________________________________
> From: Jaroslav Kysela <perex@perex.cz>
> Sent: Friday, March 6, 2015 12:21 AM
> To: Srinivasan S
> Cc: alsa-devel@alsa-project.org
> Subject: Re: snd-aloop not working in linux-3.12.10
>
> Dne 5.3.2015 v 17:42 Srinivasan S napsal(a):
>> Thanks for your replies,
>>
>> I even tried in the below linux host machine first ie., ubuntu 12.04 prior trying in embedded board
>> Linux srinivasan-Latitude-3440 3.13.0-43-generic #72~precise1-Ubuntu SMP Tue Dec 9 12:14:18 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
>>
>> am getting the below
>>
>>> card 1, device 0
>>> card 1, device 1
>>
>> aplay -D hw:1,0,0 TangoForTajMusic11.wav
>>
>> arecord -D hw:1,1,0 record .wav
>>
>> Still this is not working in the linux host machine
>>
>> Could you please help me out in resolving this issue in host machine
>
> On my host, kernel 3.17.8-200.fc20.x86_64, loopback card is #3:
>
> $ aplay -D plughw:3,0,0 /usr/share/sounds/alsa/Noise.wav
> Playing WAVE '/usr/share/sounds/alsa/Noise.wav' : Signed 16 bit Little
> Endian, Rate 48000 Hz, Mono
> $ arecord -D plughw:3,1,0 -f dat -c 1 a.wav
> Recording WAVE 'a.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono
>
> As you see, the "capture" program must set the same parameters as the
> sample provider.
>
> This also works:
>
> $ alsaloop -C hw:3,1 -P plughw:1 -t 50000
>
> The "plughw:1" is the real sound hardware in this case (first device,
> second soundcard #1). The aplay command is same as in the first example
> with device "plughw:3,0,0". In this case, the alsaloop detects the PCM
> stream paramter changes automatically using the control API:
>
> $ amixer -c 3 controls
> numid=2,iface=PCM,name='PCM Notify'
> numid=1,iface=PCM,name='PCM Rate Shift 100000'
> numid=3,iface=PCM,name='PCM Slave Active'
> numid=6,iface=PCM,name='PCM Slave Channels'
> numid=4,iface=PCM,name='PCM Slave Format'
> numid=5,iface=PCM,name='PCM Slave Rate'
> numid=8,iface=PCM,name='PCM Notify',subdevice=1
> numid=7,iface=PCM,name='PCM Rate Shift 100000',subdevice=1
> numid=9,iface=PCM,name='PCM Slave Active',subdevice=1
>
>
>                                         Jaroslav
>
>
>>
>> Thanks in advance
>>
>>
>>
>> ________________________________________
>> From: Jaroslav Kysela <perex@perex.cz>
>> Sent: Thursday, March 5, 2015 7:43 PM
>> To: Srinivasan S
>> Cc: alsa-devel@alsa-project.org
>> Subject: Re: snd-aloop not working in linux-3.12.10
>>
>> Dne 5.3.2015 v 14:45 Srinivasan S napsal(a):
>>> Dear Jaroslav
>>>
>>> As this feature ie., snd-aloop designed by you,  could you please redirect to the respective links where my queries can be posted & get the solutions for the problem
>>
>> No idea. It looks like you are asking for a commercial support.
>> It may be a cache coherency issue or something else. The embedded/ARM
>> platforms might behave completely differently than x86 on which
>> this code was developed and tested.
>>
>>                                 Jaroslav
>>
>>>
>>> As we are trying to establish GSM two way calls via stereo codec
>>>
>>> We are planning to use loopback module (ie.,snd-aloop and alsaloop in ti sdk 7) to connect the sink/source and source/sink GSM and Codec.
>>>
>>> The below is the virtual devices created after configuring snd-aloop in the linux kernel 3.12.10
>>>
>>> card 0, device 0
>>> card 0, device 1
>>>
>>> whatever am playing we are unable to record in the virtual device, but we are able to play & record with actual device
>>>
>>> aplay -D hw:0,0,0 play.wav
>>> arecord -D hw:0,1,0 record.wav or alsaloop -C hw:0,1 -P hw:0,0 -t 50000 # second terminal, latency 50ms
>>>
>>> As per the logs below, am using the above commands to perform loopback, could you please let me know why am unable to perform the loopback with the below commands or please let me know am I missing any configurations,
>>>
>>> As this is feature is not working in ti sdk 7 (ie.,snd-aloop and alsaloop),
>>>
>>> Kindly requesting to try in your am335x-evm where it has tlv codec & verify this feature ie., snd-aloop & let me know as early as possible
>>>
>>>
>>> logs :
>>> ======
>>> root@am335x-evm:/# ls /dev/snd/
>>> by-path    controlC1  pcmC0D0p   pcmC0D1p   pcmC1D0p
>>> controlC0  pcmC0D0c   pcmC0D1c   pcmC1D0c   timer
>>> root@am335x-evm:/# cat /proc/asound/devices
>>>   0: [ 0]   : control
>>>  16: [ 0- 0]: digital audio playback
>>>  17: [ 0- 1]: digital audio playback
>>>  24: [ 0- 0]: digital audio capture
>>>  25: [ 0- 1]: digital audio capture
>>>  32: [ 1]   : control
>>>  33:        : timer
>>>  48: [ 1- 0]: digital audio playback
>>>  56: [ 1- 0]: digital audio capture
>>> root@am335x-evm:/#
>>>
>>> Loopback device
>>> ----------------
>>> root@am335x-evm:/# aplay -l
>>> **** List of PLAYBACK Hardware Devices ****
>>> card 0: Loopback [Loopback], device 0: Loopback PCM [Loopback PCM]
>>>   Subdevices: 8/8
>>>   Subdevice #0: subdevice #0
>>>   Subdevice #1: subdevice #1
>>>   Subdevice #2: subdevice #2
>>>   Subdevice #3: subdevice #3
>>>   Subdevice #4: subdevice #4
>>>   Subdevice #5: subdevice #5
>>>   Subdevice #6: subdevice #6
>>>   Subdevice #7: subdevice #7
>>> card 0: Loopback [Loopback], device 1: Loopback PCM [Loopback PCM]
>>>   Subdevices: 8/8
>>>   Subdevice #0: subdevice #0
>>>   Subdevice #1: subdevice #1
>>>   Subdevice #2: subdevice #2
>>>   Subdevice #3: subdevice #3
>>>   Subdevice #4: subdevice #4
>>>   Subdevice #5: subdevice #5
>>>   Subdevice #6: subdevice #6
>>>   Subdevice #7: subdevice #7
>>> card 1: UDA1345TS [TI UDA1345TS], device 0: UDA134x uda134x-hifi-0 []
>>>   Subdevices: 1/1
>>>   Subdevice #0: subdevice #0
>>> root@am335x-evm:/# aplay -D hw:0,0,0 TangoForTajMusic11.wav
>>> Playing WAVE 'TangoForTajMusic11.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
>>>
>>>
>>>
>>> Actual device
>>> -------------
>>> root@am335x-evm:/# aplay -D hw:1,0,0 TangoForTajMusic11.wav
>>> Playing WAVE 'TangoForTajMusic11.wav' : Signed 16 bit Li[ 2219.654309] DAVINCIIIIIIIIII UDA134XXXXX SYSCLK=12288000
>>> ttle Endian, Rate 48000 Hz, Stereo
>>> [ 2219.663776] DAVINCIIIIIIIIII UDA134XXXXX BCLK FREQQ=1536000
>>> [ 2219.672880] DAVINCIIIIIIIIII UDA134XXXXX SYSCLK/BCLK_FREQ =8
>>> [ 2219.678982] uda134x_hw_params CLOCKS uda134x_hw_params uda134x->sysclk: 12288000, params_rate(params):48000
>>> [ 2219.689474] uda134x_hw_params FORMATS uda134x_hw_params dai_fmt: 16385, params_format:2
>>> [ 2219.698095] uda134x_hw_params FORMATS uda134x_hw_params uda134x->sysclk / params_rate(params) 256
>>> [ 2219.707644] UDA1345TSSSSSSSSSSSS SYSCLK / fs ratio is 256
>>> [ 2219.713470] uda134x_hw_params dai_fmt: 16385, params_format:2
>>> [ 2219.719639] UDA1345TSSSSSSSSSSSS FORMAT SND_SOC_DAIFMT_I2S
>>> [ 2219.725716] ENTERED davinci_config_channel_size davinci_config_channel_size: tx_rotate = 4
>>> [ 2219.734620] ENTERED davinci_config_channel_size davinci_config_channel_size: MASK= 65535
>>> [ 2219.748324] uda134x_unnnnnnnnmuteeeeeeeeee uda134x_mute mute: 0
>>> [ 2219.756522] davinci_mcasp_starttttttttttttttttttttt SNDRV_PCM_STREAM_PLAYBACK
>>>
>>>
>>> Kindly do the needful as early as possible
>>> Awaiting for your replies,
>>>
>>> Many Thanks in advance,
>>
>>
>> --
>> Jaroslav Kysela <perex@perex.cz>
>> Linux Kernel Sound Maintainer
>> ALSA Project; Red Hat, Inc.
>>
>
>
> --
> Jaroslav Kysela <perex@perex.cz>
> Linux Kernel Sound Maintainer
> ALSA Project; Red Hat, Inc.
>


--
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project; Red Hat, Inc.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: snd-aloop not working in linux-3.12.10

[Srinivasan S]

Dear Jaroslav

Hope you are doing good

Am planning to use Jack plugin along with snd-aloop

Could you please let me know this is feasible for my design


1. Pls find the details of the design as below:

what ever the GSM analog audio out data is pumped as VINR to stereo codec & the output of the stereo codec ie., VOUTR is pumped to the Speaker of the custom board

what ever the GSM analog audio out data is pumped as VINR to stereo codec & the output of the stereo codec ie., VOUTR is pumped to the Speaker of the custom board
GSM MIC-> VINR -> stereo codec->VOUTR -> board speaker

what ever the board MIC data is pumped as VINL to stereo codec & the output of the stereo codec ie., VOUTL is pumped as analog input to the GSM Speaker
Board Mic -> VINL-> stereo codec -> VOUTL ->GSM speaker

2. Could you please let me know, I have downloaded jack-1.9.10.tar.bz2, how this needs to be installed in my rootfs

Pls let me know if any other details is required from my side

Thanks,
Srinivasan S














________________________________________
From: alsa-devel-bounces@alsa-project.org <alsa-devel-bounces@alsa-project.org> on behalf of Srinivasan S <srinivasan.s@tataelxsi.co.in>
Sent: Monday, March 9, 2015 10:39 AM
To: Jaroslav Kysela
Cc: alsa-devel@alsa-project.org
Subject: Re: [alsa-devel] snd-aloop not working in linux-3.12.10

Dear Jaroslav,

Very Good Morning!

Could you please kindly help me in clarifying my inline doubts, as I am pretty new to linux audio particularly ALSA Framework as I was involved only in intial codec bringup using aplay & arecord utilities , as I was having some trouble getting a grasp on it all,

Once the inline doubts are calrified, I can plan my design accordingly

And you really appreciate your prompt replies for my earlier two queries

Kindly do the needful as early possible

Awaiting for your replies,

Many Many Thanks in advance again,

________________________________________
From: alsa-devel-bounces@alsa-project.org <alsa-devel-bounces@alsa-project.org> on behalf of Srinivasan S <srinivasan.s@tataelxsi.co.in>
Sent: Friday, March 6, 2015 11:13 PM
To: Jaroslav Kysela
Cc: alsa-devel@alsa-project.org
Subject: Re: [alsa-devel] snd-aloop not working in linux-3.12.10

Once again Many Thanks a lot Jaroslav, and would appreciate a lot

Now am very clear w.r.t loopback card

Basically I need two sound card devices using loopback. One is a GSM modem with a sink/source and the other is a audio codec, Using loopback module to connect the sink/source and source/sink GSM and Codec.

Could you please clarify the following points w.r.t loopback card(as am new to Alsa, Extremely sorry if this doubts seems to be silly for you)

1) As per the link http://alsa.opensrc.org/Jack_and_Loopback_device_as_Alsa-to-Jack_bridge

In the section, The Jack Bridge, ie.,Creating permanent Jack clients using alsa_in and alsa_out

Again am little bit confused in the link it is mentioned that

ie., Since we used subdevice 0,0 for playback and subdevice 0,1 for capture,
I didn't understand that how the signal will be available in subdevice 1,0, which alsa_in listens to. The "cloop" client we created can now be connected to the jack system output ports and o miracle, you will hear your ALSA app :)

Could you please help me out in understanding

# capture client
alsa_in -j cloop -dcloop

# playback client
alsa_out -j ploop -dploop

ie., Is it possible to record using alsa_in & is it possible to playback the same recorded data using alsa_out independently?? or does it has any interdependencies on the loopback card as we discussed earlier (ie., for example in your case loopbackcard hw:3,0 (playback) & loopbackcard hw:3,1 (capture) )

2)Regarding w.r.t alsaloop
aplay -D plughw:1,0 <your_wav_file>
alsaloop -C hw:1,1 -P hw:0,0 -t 50000

i) Could you please clarify ie., alsaloop does this performs the same as one playback device to another capture device
so it returns them to the userspace. ie., after aplay only alsaloop can be used or what??

ii) Could you please clarify ,inorder to use alsaloop is it mandatory to have amixer controls,
I didn't understand as what you said that is  alsaloop detects the PCM
stream paramter changes automatically using the control API ie., amixer -c 3 controls


Kindly do the needful as early as possible

Awaiting for your replies

Once again Many Thanks a lot for your prompt support w.r.t snd-aloop

________________________________________
From: Jaroslav Kysela <perex@perex.cz>
Sent: Friday, March 6, 2015 4:58 PM
To: Srinivasan S
Cc: alsa-devel@alsa-project.org
Subject: Re: snd-aloop not working in linux-3.12.10

Dne 6.3.2015 v 11:35 Srinivasan S napsal(a):
> Once again many Thanks for the quick responses,
>
> Could you please try  & let me know whether does it works viceversa ie., arecord on loopback card first & then aplay on the loopback card as shown below
>
> $ arecord -D plughw:3,1,0 -f dat -c 1 a.wav
> Recording WAVE 'a.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono
>
> $ aplay -D plughw:3,0,0 a.wav
> Playing WAVE '/usr/share/sounds/alsa/Noise.wav' : Signed 16 bit Little
> Endian, Rate 48000 Hz, Mono
>
> Awaiting for your replies,

I'm not sure, if you understand the purpose of the loopback card. It
just passes the data from one playback device to another capture device
so it returns them to the userspace. So you need to have an input
(source) to be loopbacked. You're probably trying to loopback the zero
(silence) samples which are provided when the source is not available
from the loopback card.

You cannot do (simple notation):

arecord Loopback,1 | aplay Loopback,0

it's endless silence loop, but you can do (both commands should be
executed at same time):

aplay Loopback,0 <some_wav_file_with_real_content>
arecord Loopback,1 <loopbacked_result_stored_to_wav>

                                        Jaroslav

>
> Thanks in advance again.
> Srinivasan S
>
>
> ________________________________________
> From: Jaroslav Kysela <perex@perex.cz>
> Sent: Friday, March 6, 2015 12:21 AM
> To: Srinivasan S
> Cc: alsa-devel@alsa-project.org
> Subject: Re: snd-aloop not working in linux-3.12.10
>
> Dne 5.3.2015 v 17:42 Srinivasan S napsal(a):
>> Thanks for your replies,
>>
>> I even tried in the below linux host machine first ie., ubuntu 12.04 prior trying in embedded board
>> Linux srinivasan-Latitude-3440 3.13.0-43-generic #72~precise1-Ubuntu SMP Tue Dec 9 12:14:18 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
>>
>> am getting the below
>>
>>> card 1, device 0
>>> card 1, device 1
>>
>> aplay -D hw:1,0,0 TangoForTajMusic11.wav
>>
>> arecord -D hw:1,1,0 record .wav
>>
>> Still this is not working in the linux host machine
>>
>> Could you please help me out in resolving this issue in host machine
>
> On my host, kernel 3.17.8-200.fc20.x86_64, loopback card is #3:
>
> $ aplay -D plughw:3,0,0 /usr/share/sounds/alsa/Noise.wav
> Playing WAVE '/usr/share/sounds/alsa/Noise.wav' : Signed 16 bit Little
> Endian, Rate 48000 Hz, Mono
> $ arecord -D plughw:3,1,0 -f dat -c 1 a.wav
> Recording WAVE 'a.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono
>
> As you see, the "capture" program must set the same parameters as the
> sample provider.
>
> This also works:
>
> $ alsaloop -C hw:3,1 -P plughw:1 -t 50000
>
> The "plughw:1" is the real sound hardware in this case (first device,
> second soundcard #1). The aplay command is same as in the first example
> with device "plughw:3,0,0". In this case, the alsaloop detects the PCM
> stream paramter changes automatically using the control API:
>
> $ amixer -c 3 controls
> numid=2,iface=PCM,name='PCM Notify'
> numid=1,iface=PCM,name='PCM Rate Shift 100000'
> numid=3,iface=PCM,name='PCM Slave Active'
> numid=6,iface=PCM,name='PCM Slave Channels'
> numid=4,iface=PCM,name='PCM Slave Format'
> numid=5,iface=PCM,name='PCM Slave Rate'
> numid=8,iface=PCM,name='PCM Notify',subdevice=1
> numid=7,iface=PCM,name='PCM Rate Shift 100000',subdevice=1
> numid=9,iface=PCM,name='PCM Slave Active',subdevice=1
>
>
>                                         Jaroslav
>
>
>>
>> Thanks in advance
>>
>>
>>
>> ________________________________________
>> From: Jaroslav Kysela <perex@perex.cz>
>> Sent: Thursday, March 5, 2015 7:43 PM
>> To: Srinivasan S
>> Cc: alsa-devel@alsa-project.org
>> Subject: Re: snd-aloop not working in linux-3.12.10
>>
>> Dne 5.3.2015 v 14:45 Srinivasan S napsal(a):
>>> Dear Jaroslav
>>>
>>> As this feature ie., snd-aloop designed by you,  could you please redirect to the respective links where my queries can be posted & get the solutions for the problem
>>
>> No idea. It looks like you are asking for a commercial support.
>> It may be a cache coherency issue or something else. The embedded/ARM
>> platforms might behave completely differently than x86 on which
>> this code was developed and tested.
>>
>>                                 Jaroslav
>>
>>>
>>> As we are trying to establish GSM two way calls via stereo codec
>>>
>>> We are planning to use loopback module (ie.,snd-aloop and alsaloop in ti sdk 7) to connect the sink/source and source/sink GSM and Codec.
>>>
>>> The below is the virtual devices created after configuring snd-aloop in the linux kernel 3.12.10
>>>
>>> card 0, device 0
>>> card 0, device 1
>>>
>>> whatever am playing we are unable to record in the virtual device, but we are able to play & record with actual device
>>>
>>> aplay -D hw:0,0,0 play.wav
>>> arecord -D hw:0,1,0 record.wav or alsaloop -C hw:0,1 -P hw:0,0 -t 50000 # second terminal, latency 50ms
>>>
>>> As per the logs below, am using the above commands to perform loopback, could you please let me know why am unable to perform the loopback with the below commands or please let me know am I missing any configurations,
>>>
>>> As this is feature is not working in ti sdk 7 (ie.,snd-aloop and alsaloop),
>>>
>>> Kindly requesting to try in your am335x-evm where it has tlv codec & verify this feature ie., snd-aloop & let me know as early as possible
>>>
>>>
>>> logs :
>>> ======
>>> root@am335x-evm:/# ls /dev/snd/
>>> by-path    controlC1  pcmC0D0p   pcmC0D1p   pcmC1D0p
>>> controlC0  pcmC0D0c   pcmC0D1c   pcmC1D0c   timer
>>> root@am335x-evm:/# cat /proc/asound/devices
>>>   0: [ 0]   : control
>>>  16: [ 0- 0]: digital audio playback
>>>  17: [ 0- 1]: digital audio playback
>>>  24: [ 0- 0]: digital audio capture
>>>  25: [ 0- 1]: digital audio capture
>>>  32: [ 1]   : control
>>>  33:        : timer
>>>  48: [ 1- 0]: digital audio playback
>>>  56: [ 1- 0]: digital audio capture
>>> root@am335x-evm:/#
>>>
>>> Loopback device
>>> ----------------
>>> root@am335x-evm:/# aplay -l
>>> **** List of PLAYBACK Hardware Devices ****
>>> card 0: Loopback [Loopback], device 0: Loopback PCM [Loopback PCM]
>>>   Subdevices: 8/8
>>>   Subdevice #0: subdevice #0
>>>   Subdevice #1: subdevice #1
>>>   Subdevice #2: subdevice #2
>>>   Subdevice #3: subdevice #3
>>>   Subdevice #4: subdevice #4
>>>   Subdevice #5: subdevice #5
>>>   Subdevice #6: subdevice #6
>>>   Subdevice #7: subdevice #7
>>> card 0: Loopback [Loopback], device 1: Loopback PCM [Loopback PCM]
>>>   Subdevices: 8/8
>>>   Subdevice #0: subdevice #0
>>>   Subdevice #1: subdevice #1
>>>   Subdevice #2: subdevice #2
>>>   Subdevice #3: subdevice #3
>>>   Subdevice #4: subdevice #4
>>>   Subdevice #5: subdevice #5
>>>   Subdevice #6: subdevice #6
>>>   Subdevice #7: subdevice #7
>>> card 1: UDA1345TS [TI UDA1345TS], device 0: UDA134x uda134x-hifi-0 []
>>>   Subdevices: 1/1
>>>   Subdevice #0: subdevice #0
>>> root@am335x-evm:/# aplay -D hw:0,0,0 TangoForTajMusic11.wav
>>> Playing WAVE 'TangoForTajMusic11.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
>>>
>>>
>>>
>>> Actual device
>>> -------------
>>> root@am335x-evm:/# aplay -D hw:1,0,0 TangoForTajMusic11.wav
>>> Playing WAVE 'TangoForTajMusic11.wav' : Signed 16 bit Li[ 2219.654309] DAVINCIIIIIIIIII UDA134XXXXX SYSCLK=12288000
>>> ttle Endian, Rate 48000 Hz, Stereo
>>> [ 2219.663776] DAVINCIIIIIIIIII UDA134XXXXX BCLK FREQQ=1536000
>>> [ 2219.672880] DAVINCIIIIIIIIII UDA134XXXXX SYSCLK/BCLK_FREQ =8
>>> [ 2219.678982] uda134x_hw_params CLOCKS uda134x_hw_params uda134x->sysclk: 12288000, params_rate(params):48000
>>> [ 2219.689474] uda134x_hw_params FORMATS uda134x_hw_params dai_fmt: 16385, params_format:2
>>> [ 2219.698095] uda134x_hw_params FORMATS uda134x_hw_params uda134x->sysclk / params_rate(params) 256
>>> [ 2219.707644] UDA1345TSSSSSSSSSSSS SYSCLK / fs ratio is 256
>>> [ 2219.713470] uda134x_hw_params dai_fmt: 16385, params_format:2
>>> [ 2219.719639] UDA1345TSSSSSSSSSSSS FORMAT SND_SOC_DAIFMT_I2S
>>> [ 2219.725716] ENTERED davinci_config_channel_size davinci_config_channel_size: tx_rotate = 4
>>> [ 2219.734620] ENTERED davinci_config_channel_size davinci_config_channel_size: MASK= 65535
>>> [ 2219.748324] uda134x_unnnnnnnnmuteeeeeeeeee uda134x_mute mute: 0
>>> [ 2219.756522] davinci_mcasp_starttttttttttttttttttttt SNDRV_PCM_STREAM_PLAYBACK
>>>
>>>
>>> Kindly do the needful as early as possible
>>> Awaiting for your replies,
>>>
>>> Many Thanks in advance,
>>
>>
>> --
>> Jaroslav Kysela <perex@perex.cz>
>> Linux Kernel Sound Maintainer
>> ALSA Project; Red Hat, Inc.
>>
>
>
> --
> Jaroslav Kysela <perex@perex.cz>
> Linux Kernel Sound Maintainer
> ALSA Project; Red Hat, Inc.
>


--
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project; Red Hat, Inc.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel