[alsa-devel] [ALSA-UTILS][PATCH] Add support for cplay and crecord
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
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
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
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
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?
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
- copying code will cause more maintaince of same code in two places :(
- 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
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
- copying code will cause more maintaince of same code in two places :(
- 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... ?
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
- copying code will cause more maintaince of same code in two places :(
- 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
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
- copying code will cause more maintaince of same code in two places :(
- 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.
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
- copying code will cause more maintaince of same code in two places :(
- 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
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
- copying code will cause more maintaince of same code in two places :(
- 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
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,
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.
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.
JaroslavAs 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.
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.
JaroslavAs 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.
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
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
JaroslavThanks 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.
JaroslavAs 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.
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
JaroslavThanks 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.
JaroslavAs 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.
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
JaroslavThanks 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.
JaroslavAs 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
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
JaroslavThanks 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.
JaroslavAs 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
participants (5)
-
Jaroslav Kysela -
Qais Yousef -
Srinivasan S -
Takashi Iwai -
Vinod Koul