Re: [alsa-devel] [Q] playing / recording mono on a stereo-only hardware
(re-adding the list)
On Tue, 2 Feb 2010, Michael Trimarchi wrote:
Hi,
Guennadi Liakhovetski wrote:
On Sat, 30 Jan 2010, Michael Trimarchi wrote:
Guennadi Liakhovetski wrote:
Hi
I know this question belongs rather to alsa-users, and I did ask it there, but got no solution so far. Maybe someone here can help.
The recently posted SuperH SIU driver only supports stereo playback and capture (channels_min = channels_max = 2). Is there a way to tell alsa-lib to duplicate the mono-channel during playback and to mix recorded channels (or use one of them), if mono recording is requested?
I'm not an expert but I think that you can use plughw support of alsa-lib
pcm.record { type plug slave { pcm record_hw } route_policy average rate_converter "linear" }
I think that automatically change rate and channel for supporting mono channel too
Thanks for the snippet, but, I'm afraid, it didn't help either.
Sorry can you explain a little bit more why it doesn't help you?
I certainly gladly would explain this, if only I knew... It just doesn't change anything. Are you using it anywhere? If yes, with which hardware configuration and software (alsa-lib) versions?
Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/
Guennadi Liakhovetski wrote:
(re-adding the list)
On Tue, 2 Feb 2010, Michael Trimarchi wrote:
Hi,
Guennadi Liakhovetski wrote:
On Sat, 30 Jan 2010, Michael Trimarchi wrote:
Guennadi Liakhovetski wrote:
Hi
I know this question belongs rather to alsa-users, and I did ask it there, but got no solution so far. Maybe someone here can help.
The recently posted SuperH SIU driver only supports stereo playback and capture (channels_min = channels_max = 2). Is there a way to tell alsa-lib to duplicate the mono-channel during playback and to mix recorded channels (or use one of them), if mono recording is requested?
I'm not an expert but I think that you can use plughw support of alsa-lib
pcm.record { type plug slave { pcm record_hw } route_policy average rate_converter "linear" }
I think that automatically change rate and channel for supporting mono channel too
Thanks for the snippet, but, I'm afraid, it didn't help either.
Sorry can you explain a little bit more why it doesn't help you?
I certainly gladly would explain this, if only I knew... It just doesn't change anything. Are you using it anywhere? If yes, with which hardware configuration and software (alsa-lib) versions?
alsa-lib 1.0.16
#define BUILD_PCM_PLUGIN_RATE "1" #define BUILD_PCM_PLUGIN_ROUTE "1"
Hardware android openmoko gta02. Test it with arecord 1 month ago
Android
Michael
Thanks Guennadi
Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
On Tue, 2 Feb 2010, Michael Trimarchi wrote:
Guennadi Liakhovetski wrote:
(re-adding the list)
On Tue, 2 Feb 2010, Michael Trimarchi wrote:
Hi,
Guennadi Liakhovetski wrote:
On Sat, 30 Jan 2010, Michael Trimarchi wrote:
Guennadi Liakhovetski wrote:
Hi
I know this question belongs rather to alsa-users, and I did ask it there, but got no solution so far. Maybe someone here can help.
The recently posted SuperH SIU driver only supports stereo playback and capture (channels_min = channels_max = 2). Is there a way to tell alsa-lib to duplicate the mono-channel during playback and to mix recorded channels (or use one of them), if mono recording is requested?
I'm not an expert but I think that you can use plughw support of alsa-lib
pcm.record { type plug slave { pcm record_hw } route_policy average rate_converter "linear" }
I think that automatically change rate and channel for supporting mono channel too
Thanks for the snippet, but, I'm afraid, it didn't help either.
Sorry can you explain a little bit more why it doesn't help you?
I certainly gladly would explain this, if only I knew... It just doesn't change anything. Are you using it anywhere? If yes, with which hardware configuration and software (alsa-lib) versions?
alsa-lib 1.0.16
1.0.22 here.
#define BUILD_PCM_PLUGIN_RATE "1" #define BUILD_PCM_PLUGIN_ROUTE "1"
Yes, have these in include/config.h too.
Hardware android openmoko gta02. Test it with arecord 1 month ago
Ok, looks like openmoko has a few configurations, of which some are just mono, and the I2S is, of course, stereo only. So, did this work with the HiFi (I2S) interface and not with bluetooth?
Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/
Guennadi Liakhovetski wrote:
On Tue, 2 Feb 2010, Michael Trimarchi wrote:
Guennadi Liakhovetski wrote:
(re-adding the list)
On Tue, 2 Feb 2010, Michael Trimarchi wrote:
Hi,
Guennadi Liakhovetski wrote:
On Sat, 30 Jan 2010, Michael Trimarchi wrote:
Guennadi Liakhovetski wrote:
> Hi > > I know this question belongs rather to alsa-users, and I did ask it > there, > but got no solution so far. Maybe someone here can help. > > The recently posted SuperH SIU driver only supports stereo playback > and > capture (channels_min = channels_max = 2). Is there a way to tell > alsa-lib > to duplicate the mono-channel during playback and to mix recorded > channels > (or use one of them), if mono recording is requested? > > I'm not an expert but I think that you can use plughw support of alsa-lib
pcm.record { type plug slave { pcm record_hw } route_policy average rate_converter "linear" }
I think that automatically change rate and channel for supporting mono channel too
Thanks for the snippet, but, I'm afraid, it didn't help either.
Sorry can you explain a little bit more why it doesn't help you?
I certainly gladly would explain this, if only I knew... It just doesn't change anything. Are you using it anywhere? If yes, with which hardware configuration and software (alsa-lib) versions?
alsa-lib 1.0.16
1.0.22 here.
#define BUILD_PCM_PLUGIN_RATE "1" #define BUILD_PCM_PLUGIN_ROUTE "1"
Yes, have these in include/config.h too.
Hardware android openmoko gta02. Test it with arecord 1 month ago
Ok, looks like openmoko has a few configurations, of which some are just mono, and the I2S is, of course, stereo only. So, did this work with the HiFi (I2S) interface and not with bluetooth?
I have tested it on the no-bluetooth interface. What is your testing application and the reporting error?
Michael
Thanks Guennadi
Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/
On Tue, 2 Feb 2010, Michael Trimarchi wrote:
I have tested it on the no-bluetooth interface. What is your testing application and the reporting error?
Using aplayer / arecord, I posted a couple of logs in other threads, see, e.g., http://thread.gmane.org/gmane.linux.alsa.user/33861 and a log with some debugging http://pastebin.ca/1773284
Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/
2010/2/3 Guennadi Liakhovetski g.liakhovetski@gmx.de
On Tue, 2 Feb 2010, Michael Trimarchi wrote:
I have tested it on the no-bluetooth interface. What is your testing application and the reporting error?
Using aplayer / arecord, I posted a couple of logs in other threads, see, e.g., http://thread.gmane.org/gmane.linux.alsa.user/33861 and a log with some debugging http://pastebin.ca/1773284
Thanks Guennadi
Try
export LIBASOUND_DEBUG=1 arecord -v -Dplughw:0,0 -c 1 -f S16_LE -r 800 -d 30 any.wav
On Wed, 3 Feb 2010, Raymond Yau wrote:
2010/2/3 Guennadi Liakhovetski g.liakhovetski@gmx.de
On Tue, 2 Feb 2010, Michael Trimarchi wrote:
I have tested it on the no-bluetooth interface. What is your testing application and the reporting error?
Using aplayer / arecord, I posted a couple of logs in other threads, see, e.g., http://thread.gmane.org/gmane.linux.alsa.user/33861 and a log with some debugging http://pastebin.ca/1773284
Thanks Guennadi
Try
export LIBASOUND_DEBUG=1 arecord -v -Dplughw:0,0 -c 1 -f S16_LE -r 800 -d 30 any.wav
No success either (with 8000Hz instead of 800):
Recording WAVE '/tmp/any.wav' : Signed 16 bit Little Endian, Rate 8000 Hz, Mono CHOOSE called: ACCESS: RW_INTERLEAVED FORMAT: S16_LE SUBFORMAT: STD SAMPLE_BITS: 16 FRAME_BITS: 16 CHANNELS: 1 RATE: 8000 PERIOD_TIME: 125000 PERIOD_SIZE: 1000 PERIOD_BYTES: 2000 PERIODS: 4 BUFFER_TIME: 500000 BUFFER_SIZE: 4000 BUFFER_BYTES: 8000 TICK_TIME: ALL choose done ACCESS: RW_INTERLEAVED FORMAT: S16_LE SUBFORMAT: STD SAMPLE_BITS: 16 FRAME_BITS: 16 CHANNELS: 1 RATE: 8000 PERIOD_TIME: 125000 PERIOD_SIZE: 1000 PERIOD_BYTES: 2000 PERIODS: 4 BUFFER_TIME: 500000 BUFFER_SIZE: 4000 BUFFER_BYTES: 8000 TICK_TIME: 0 arecord: set_params:1053: Unable to install hw params: ACCESS: RW_INTERLEAVED FORMAT: S16_LE SUBFORMAT: STD SAMPLE_BITS: 16 FRAME_BITS: 16 CHANNELS: 1 RATE: 8000 PERIOD_TIME: 125000 PERIOD_SIZE: 1000 PERIOD_BYTES: 2000 PERIODS: 4 BUFFER_TIME: 500000 BUFFER_SIZE: 4000 BUFFER_BYTES: 8000 TICK_TIME: 0
Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/
2010/2/4 Guennadi Liakhovetski g.liakhovetski@gmx.de
On Wed, 3 Feb 2010, Raymond Yau wrote:
2010/2/3 Guennadi Liakhovetski g.liakhovetski@gmx.de
On Tue, 2 Feb 2010, Michael Trimarchi wrote:
I have tested it on the no-bluetooth interface. What is your testing application and the reporting error?
Using aplayer / arecord, I posted a couple of logs in other threads,
see,
e.g., http://thread.gmane.org/gmane.linux.alsa.user/33861 and a log
with
some debugging http://pastebin.ca/1773284
Thanks Guennadi
Try
export LIBASOUND_DEBUG=1 arecord -v -Dplughw:0,0 -c 1 -f S16_LE -r 800 -d 30 any.wav
No success either (with 8000Hz instead of 800):
Recording WAVE '/tmp/any.wav' : Signed 16 bit Little Endian, Rate 8000 Hz, Mono CHOOSE called: ACCESS: RW_INTERLEAVED FORMAT: S16_LE SUBFORMAT: STD SAMPLE_BITS: 16 FRAME_BITS: 16 CHANNELS: 1 RATE: 8000 PERIOD_TIME: 125000 PERIOD_SIZE: 1000 PERIOD_BYTES: 2000 PERIODS: 4 BUFFER_TIME: 500000 BUFFER_SIZE: 4000 BUFFER_BYTES: 8000 TICK_TIME: ALL choose done ACCESS: RW_INTERLEAVED FORMAT: S16_LE SUBFORMAT: STD SAMPLE_BITS: 16 FRAME_BITS: 16 CHANNELS: 1 RATE: 8000 PERIOD_TIME: 125000 PERIOD_SIZE: 1000 PERIOD_BYTES: 2000 PERIODS: 4 BUFFER_TIME: 500000 BUFFER_SIZE: 4000 BUFFER_BYTES: 8000 TICK_TIME: 0 arecord: set_params:1053: Unable to install hw params: ACCESS: RW_INTERLEAVED FORMAT: S16_LE SUBFORMAT: STD SAMPLE_BITS: 16 FRAME_BITS: 16 CHANNELS: 1 RATE: 8000 PERIOD_TIME: 125000 PERIOD_SIZE: 1000 PERIOD_BYTES: 2000 PERIODS: 4 BUFFER_TIME: 500000 BUFFER_SIZE: 4000 BUFFER_BYTES: 8000 TICK_TIME: 0
Thanks Guennadi
if LIBASOUND_DEBUG = 1 cannot tell you which parameter fail in hw_params() , you will need to define RULES_DEBUG in alsa-kernel/core/pcm_native.c and compile driver with debug=verbose
-#undef RULES_DEBUG +#define RULES DEBUG 1
you can find out how ALSA refine the hw parameters by examing the system log
On Thu, 4 Feb 2010, Raymond Yau wrote:
I would see your reply sooner, if you used reply-to-all.
if LIBASOUND_DEBUG = 1 cannot tell you which parameter fail in hw_params() , you will need to define RULES_DEBUG in alsa-kernel/core/pcm_native.c and compile driver with debug=verbose
-#undef RULES_DEBUG +#define RULES DEBUG 1
That's already on too. Not sure what you mean by "compile driver with debug=verbose," supposedly, some kernel ALSA debug parameter. Since this is my driver, I can certainly add any debugging there, but it seems obvious to me, that the kernel is still getting a mono configuration, which shouldn't be the cae.
you can find out how ALSA refine the hw parameters by examing the system log
If you mean "dmesg" output, then, as I said, there isn't much to look for there - the kernel is configured for mono...
Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/
2010/2/5 Guennadi Liakhovetski g.liakhovetski@gmx.de
On Thu, 4 Feb 2010, Raymond Yau wrote:
I would see your reply sooner, if you used reply-to-all.
if LIBASOUND_DEBUG = 1 cannot tell you which parameter fail in
hw_params() ,
you will need to define RULES_DEBUG in alsa-kernel/core/pcm_native.c and compile driver with debug=verbose
-#undef RULES_DEBUG +#define RULES DEBUG 1
That's already on too. Not sure what you mean by "compile driver with debug=verbose," supposedly, some kernel ALSA debug parameter. Since this is my driver, I can certainly add any debugging there, but it seems obvious to me, that the kernel is still getting a mono configuration, which shouldn't be the cae.
you can find out how ALSA refine the hw parameters by examing the system
log
If you mean "dmesg" output, then, as I said, there isn't much to look for there - the kernel is configured for mono...
Thanks Guennadi
your output is quite different from mine
arecord -v -f cd -c 1 -d 30 -r 8000 -Dplughw:1,0 any.wav Recording WAVE 'any.wav' : Signed 16 bit Little Endian, Rate 8000 Hz, Mono Plug PCM: Route conversion PCM (sformat=S16_LE) Transformation table: 0 <- 0*0.5 + 1*0.5 Its setup is: stream : CAPTURE access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 1 rate : 8000 exact rate : 8000 (8000/1) msbits : 16 buffer_size : 3968 period_size : 992 period_time : 124000 tstamp_mode : NONE period_step : 1 avail_min : 992 period_event : 0 start_threshold : 1 stop_threshold : 3968 silence_threshold: 0 silence_size : 0 boundary : 2080374784 Slave: Hardware PCM card 1 'HDA Intel' device 0 subdevice 0 Its setup is: stream : CAPTURE access : MMAP_INTERLEAVED format : S16_LE subformat : STD channels : 2
On Fri, 5 Feb 2010, Raymond Yau wrote:
2010/2/5 Guennadi Liakhovetski g.liakhovetski@gmx.de
On Thu, 4 Feb 2010, Raymond Yau wrote:
I would see your reply sooner, if you used reply-to-all.
if LIBASOUND_DEBUG = 1 cannot tell you which parameter fail in
hw_params() ,
you will need to define RULES_DEBUG in alsa-kernel/core/pcm_native.c and compile driver with debug=verbose
-#undef RULES_DEBUG +#define RULES DEBUG 1
That's already on too. Not sure what you mean by "compile driver with debug=verbose," supposedly, some kernel ALSA debug parameter. Since this is my driver, I can certainly add any debugging there, but it seems obvious to me, that the kernel is still getting a mono configuration, which shouldn't be the cae.
you can find out how ALSA refine the hw parameters by examing the system
log
If you mean "dmesg" output, then, as I said, there isn't much to look for there - the kernel is configured for mono...
Thanks Guennadi
your output is quite different from mine
arecord -v -f cd -c 1 -d 30 -r 8000 -Dplughw:1,0 any.wav Recording WAVE 'any.wav' : Signed 16 bit Little Endian, Rate 8000 Hz, Mono Plug PCM: Route conversion PCM (sformat=S16_LE) Transformation table: 0 <- 0*0.5 + 1*0.5 Its setup is: stream : CAPTURE access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 1 rate : 8000 exact rate : 8000 (8000/1) msbits : 16 buffer_size : 3968 period_size : 992 period_time : 124000 tstamp_mode : NONE period_step : 1 avail_min : 992 period_event : 0 start_threshold : 1 stop_threshold : 3968 silence_threshold: 0 silence_size : 0 boundary : 2080374784 Slave: Hardware PCM card 1 'HDA Intel' device 0 subdevice 0 Its setup is: stream : CAPTURE access : MMAP_INTERLEAVED format : S16_LE subformat : STD channels : 2
Of course, in my case set_params() in aplay.c exit earlier as snd_pcm_hw_params() returns an error - see
Unable to install hw params:
message in my log. Maybe you could try current alsa-lib and alsa-util versions?
Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/
participants (3)
-
Guennadi Liakhovetski
-
Michael Trimarchi
-
Raymond Yau