From: Juan Carlos Castro y Castro <jcastro@instant.com.br>
To: Takashi Iwai <tiwai@suse.de>
Cc: alsa-devel@lists.sourceforge.net
Subject: Re: A better pcm_file "infile" patch, and a declaration of being miffed.
Date: Fri, 19 May 2006 10:45:32 -0300 [thread overview]
Message-ID: <446DCBFC.6020703@instant.com.br> (raw)
In-Reply-To: <s5hr72qxppf.wl%tiwai@suse.de>
Takashi Iwai wrote:
>At Thu, 18 May 2006 13:29:36 -0300,
>Juan Carlos Castro y Castro wrote:
>
>
>>OK, this implements the "infile" parameter of pcm_file in a much cleaner
>>way. Note that the the below new members of snd_pcm_file_t are not used
>>now, but WILL be when I implement protection from fraction-of-frame reads:
>>
>> size_t rbuf_size_bytes;
>> size_t rbuf_used_bytes;
>> char *rbuf;
>>
>>Now, the whole reason of this shebang was so I can use the "infile" AND
>>convert rates in the process -- i.e., the app programs its microphone in
>>whatever rate/format it wants, and ALSA converts the sound from the
>>existing format to what the app needs.
>>
>>The exact opposite of this already works for output -- I can force a
>>file to be written in the same format, no matter how the app configures
>>its sound output. For this, I use the .asoundrc that's also attached.
>>But it doesn't work for input. Can someone help me?
>>
>>
>I guess it works if you point a real mic PCM device as slave but still
>using infile?
>
>
It will ignore the microphone and read from the file instead. The
typical use, therefore, is with the null plugin as slave.
If you want to mix a file and a live input (say, for making a narration
with ambient music), I suppose there are ways to do that with dmix, am I
correct? (Hmmm, this could have a "loop" option)
My problem is different, it's rate & format conversion. I want to be
able to use an specific existing file as input even if the app programs
the "microphone" for a different rate/format. I'm almost certain there
is a way to do that with existing ALSA plugins (plug? dmix?) but I've
been unable to find it out on my own. :(
>The patch looks almost OK. But please don't forget to add the
>description of new parameter in the doxygen comment (in \section
>pcm_plugins_file Plugin: File), too.
>
>Also, please provide a changelog and a signed-off-by line, e.g.
>
> The short summary in a line...
>
> A detailed change log...
> ....
>
> Signed-off-by: Foo Bar <foo@bar.com>
>
>
Will do.
Cheers,
Juan
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
prev parent reply other threads:[~2006-05-19 13:45 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-18 16:29 A better pcm_file "infile" patch, and a declaration of being miffed Juan Carlos Castro y Castro
2006-05-19 10:40 ` Takashi Iwai
2006-05-19 13:45 ` Juan Carlos Castro y Castro [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=446DCBFC.6020703@instant.com.br \
--to=jcastro@instant.com.br \
--cc=alsa-devel@lists.sourceforge.net \
--cc=tiwai@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox