Re: [PATCH v2 00/27] Revised full patchset for PCM in-kernel copy support
On Jul 02 2017 05:58, Takashi Iwai wrote:
Hi,
this is a full patchset of what I sent previously, containing the all
changes instead of the snippet. The main purpose of this patchset is
to eliminate the remaining usages of set_fs(). They are basically
used for in-kernel PCM data transfer, and this patch provides the new
API functions and replaces the hackish set_fs() calls with them.
Unlike the first patchset with the unified copy_silence ops, this adds
a new copy_kernel ops instead. At the same time, copy/silence are
changed to receive the position and size in bytes instead of frames.
This allows us to simplify the PCM core code. As a result, a good
amount of code could be removed from pcm_lib.c.
The difference from the previous patchset is that this is a full
patchset, i.e. all relevant drivers have been covered, and also some
small issues have been addressed, in addition, the documentation
update is provided, too.
I'm Cc'ing the media and the USB people since it touches solo6x10 and
usb-gadget drivers.
The previous ACK was dropped as each patch was rewritten again. Sorry
for the doubly patch-review labours.
thanks,
Takashi
===
Takashi Iwai (26):
ALSA: pcm: Introduce copy_user, copy_kernel and fill_silence ops
Below commits look good to me.
ALSA: dummy: Convert to new PCM copy ops
ALSA: es1938: Convert to the new PCM copy ops
ALSA: nm256: Convert to new PCM copy ops
ALSA: korg1212: Convert to the new PCM ops
ALSA: rme32: Convert to the new PCM copy ops
ALSA: rme96: Convert to the new PCM ops
ALSA: rme9652: Convert to the new PCM ops
ALSA: hdsp: Convert to the new PCM ops
ALSA: gus: Convert to the new PCM ops
ALSA: sb: Convert to the new PCM ops
ALSA: sh: Convert to the new PCM ops
ASoC: blackfin: Convert to the new PCM ops
[media] solo6x10: Convert to the new PCM ops
ALSA: pcm: Drop the old copy and silence ops
ALSA: pcm: Check PCM state by a common helper function
ALSA: pcm: Shuffle codes
ALSA: pcm: Call directly the common read/write helpers
ALSA: pcm: More unification of PCM transfer codes
ALSA: pcm: Unify read/write loop
ALSA: pcm: Simplify snd_pcm_playback_silence()
ALSA: pcm: Direct in-kernel read/write support
usb: gadget: u_uac1: Kill set_fs() usage
ALSA: pcm: Kill set_fs() in PCM OSS layer
ALSA: pcm: Build OSS writev/readv helpers conditionally
ALSA: doc: Update copy_user, copy_kernel and fill_silence PCM ops
Reviewed-by: Takashi Sakamoto <o-taka...@sakamocchi.jp>
I did easy test with snd-hda-intel/snd-fireworks in below conditions.
Things work well:
1. ALSA application (aplay/arecord) for '__user *' <-> '__kernel *' copying.
2. loaded snd-oss-pcm and an Open Sound System application
(ossplay/ossrecord), for '__kernel *' <-> '__kernel *' copying.
I have no devices for which drivers have the .copy_user, .copy_kernel
and .fill_silence, and all of my attemps to work with OTG chip for v4.12
fails (sigh...). My test is not comprehensive at all, however the
patchset is programmed with handler-oriented ways and in this point I
think snd-pcm works as expected.
I note that patch 19 brings merge conflict to current HEAD
ee6f4cde4f74("Merge branch 'for-linus'"), due to my patch,
2c4842d3b6b3("ALSA: pcm: add local header file for snd-pcm module"). I
should have postponed it.. For the above test, I handy modifies the
history with little affections for my reviewing.
.../sound/kernel-api/writing-an-alsa-driver.rst| 111 ++--
drivers/media/pci/solo6x10/solo6x10-g723.c | 32 +-
drivers/usb/gadget/function/u_uac1.c | 7 +-
include/sound/pcm.h| 80 ++-
sound/core/oss/io.c| 4 +-
sound/core/oss/pcm_oss.c | 81 +--
sound/core/oss/pcm_plugin.h| 6 +-
sound/core/pcm_lib.c | 564 -
sound/drivers/dummy.c | 20 +-
sound/isa/gus/gus_pcm.c| 97 ++--
sound/isa/sb/emu8000_pcm.c | 190 ---
sound/pci/es1938.c | 33 +-
sound/pci/korg1212/korg1212.c | 112 ++--
sound/pci/nm256/nm256.c| 57 ++-
sound/pci/rme32.c | 65 ++-
sound/pci/rme96.c | 70 ++-
sound/pci/rme9652/hdsp.c | 67 ++-
sound/pci/rme9652/rme9652.c| 71 ++-
sound/sh/sh_dac_audio.c| 54 +-
sound/soc/blackfin/bf5xx-ac97-pcm.c| 27 +-
sound/soc/blackfin/bf5xx-i2s-pcm.c | 36 +-
sound/soc/soc-pcm.c| 5 +-
22 files changed, 977 insertions(+), 812 deletions(-)
Regards
Takashi Sakamoto
Re: [PATCH v2 53/58] firewire: don't break long lines
Hi,
On Oct 19 2016 05:46, Mauro Carvalho Chehab wrote:
> Due to the 80-cols restrictions, and latter due to checkpatch
> warnings, several strings were broken into multiple lines. This
> is not considered a good practice anymore, as it makes harder
> to grep for strings at the source code.
>
> As we're right now fixing other drivers due to KERN_CONT, we need
> to be able to identify what printk strings don't end with a "\n".
> It is a way easier to detect those if we don't break long lines.
>
> So, join those continuation lines.
>
> The patch was generated via the script below, and manually
> adjusted if needed.
>
>
> use Text::Tabs;
> while (<>) {
> if ($next ne "") {
> $c=$_;
> if ($c =~ /^\s+\"(.*)/) {
> $c2=$1;
> $next =~ s/\"\n$//;
> $n = expand($next);
> $funpos = index($n, '(');
> $pos = index($c2, '",');
> if ($funpos && $pos > 0) {
> $s1 = substr $c2, 0, $pos + 2;
> $s2 = ' ' x ($funpos + 1) . substr $c2, $pos +
> 2;
> $s2 =~ s/^\s+//;
>
> $s2 = ' ' x ($funpos + 1) . $s2 if ($s2 ne "");
>
> print unexpand("$next$s1\n");
> print unexpand("$s2\n") if ($s2 ne "");
> } else {
> print "$next$c2\n";
> }
> $next="";
> next;
> } else {
> print $next;
> }
> $next="";
> } else {
> if (m/\"$/) {
> if (!m/\\n\"$/) {
> $next=$_;
> next;
> }
> }
> }
> print $_;
> }
>
>
> Reviewed-by: Takashi Sakamoto <o-taka...@sakamocchi.jp>
> Acked-by: Stefan Richter <stef...@s5r6.in-berlin.de>
> Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>
> ---
> drivers/media/firewire/firedtv-rc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/firewire/firedtv-rc.c
> b/drivers/media/firewire/firedtv-rc.c
> index f82d4a93feb3..46dde73944df 100644
> --- a/drivers/media/firewire/firedtv-rc.c
> +++ b/drivers/media/firewire/firedtv-rc.c
> @@ -184,8 +184,8 @@ void fdtv_handle_rc(struct firedtv *fdtv, unsigned int
> code)
> else if (code >= 0x4540 && code <= 0x4542)
> code = oldtable[code - 0x4521];
> else {
> - printk(KERN_DEBUG "firedtv: invalid key code 0x%04x "
> -"from remote control\n", code);
> + printk(KERN_DEBUG "firedtv: invalid key code 0x%04x from remote
> control\n",
> +code);
> return;
> }
I realized that we can use dev_dbg() instead of the printk(). What do
you think about this patch? Anyway, the line is within 80 characters.
8<
>From da3289a04226450d6dbabb5c81155ac17c11374d Mon Sep 17 00:00:00 2001
From: Takashi Sakamoto <o-taka...@sakamocchi.jp>
Date: Wed, 19 Oct 2016 07:53:35 +0900
Subject: [PATCH] [media] firewire: use dev_dbg() instead of printk()
A structure for firedtv (struct firedtv) has a member for a pointer to
struct device. In this case, we can use dev_dbg() for debug printing.
This is more preferrable behaviour in device driver development.
Signed-off-by: Takashi Sakamoto <o-taka...@sakamocchi.jp>
---
drivers/media/firewire/firedtv-rc.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/media/firewire/firedtv-rc.c
b/drivers/media/firewire/firedtv-rc.c
index f82d4a9..04dea2a 100644
--- a/drivers/media/firewire/firedtv-rc.c
+++ b/drivers/media/firewire/firedtv-rc.c
@@ -184,8 +184,9 @@ void fdtv_handle_rc(struct firedtv *fdtv, unsigned
int code)
else if (code >= 0x4540 && code <= 0x4542)
code = oldtable[code - 0x4521];
else {
- printk(KERN_DEBUG "firedtv: invalid key code 0x%04x "
- "from remote control\n", code);
+ dev_dbg(fdtv->device,
+ "invalid key code 0x%04x from remote control\n",
+ code);
return;
}
--
2.7.4
Regards
Takashi Sakamoto
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/57] [media] firewire: don't break long lines
Hi,
On Oct 15 2016 05:19, Mauro Carvalho Chehab wrote:
> Due to the 80-cols checkpatch warnings, several strings
> were broken into multiple lines. This is not considered
> a good practice anymore, as it makes harder to grep for
> strings at the source code. So, join those continuation
> lines.
>
> Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>
I prefer this patch because of the same reason in patch comment.
Reviewed-by: Takashi Sakamoto <o-taka...@sakamocchi.jp>
> ---
> drivers/media/firewire/firedtv-avc.c | 5 +++--
> drivers/media/firewire/firedtv-rc.c | 5 +++--
> 2 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/media/firewire/firedtv-avc.c
> b/drivers/media/firewire/firedtv-avc.c
> index 251a556112a9..e04235ea23fb 100644
> --- a/drivers/media/firewire/firedtv-avc.c
> +++ b/drivers/media/firewire/firedtv-avc.c
> @@ -1181,8 +1181,9 @@ int avc_ca_pmt(struct firedtv *fdtv, char *msg, int
> length)
> if (es_info_length > 0) {
> pmt_cmd_id = msg[read_pos++];
> if (pmt_cmd_id != 1 && pmt_cmd_id != 4)
> - dev_err(fdtv->device, "invalid pmt_cmd_id %d "
> - "at stream level\n", pmt_cmd_id);
> + dev_err(fdtv->device,
> + "invalid pmt_cmd_id %d at stream
> level\n",
> + pmt_cmd_id);
>
> if (es_info_length > sizeof(c->operand) - 4 -
>write_pos) {
> diff --git a/drivers/media/firewire/firedtv-rc.c
> b/drivers/media/firewire/firedtv-rc.c
> index f82d4a93feb3..babfb9cee20e 100644
> --- a/drivers/media/firewire/firedtv-rc.c
> +++ b/drivers/media/firewire/firedtv-rc.c
> @@ -184,8 +184,9 @@ void fdtv_handle_rc(struct firedtv *fdtv, unsigned int
> code)
> else if (code >= 0x4540 && code <= 0x4542)
> code = oldtable[code - 0x4521];
> else {
> - printk(KERN_DEBUG "firedtv: invalid key code 0x%04x "
> -"from remote control\n", code);
> + printk(KERN_DEBUG
> +"firedtv: invalid key code 0x%04x from remote control\n",
> +code);
> return;
> }
Regards
Takashi Sakamoto
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 0/2] ALSA: control: export all of TLV related macros to user land
On Sep 10 2016 22:41, Takashi Iwai wrote:
> On Sat, 10 Sep 2016 09:25:31 +0200,
> Takashi Sakamoto wrote:
>>
>> On Sep 10 2016 15:44, Takashi Iwai wrote:
>>> On Sat, 10 Sep 2016 06:50:14 +0200,
>>> Takashi Sakamoto wrote:
>>>>
>>>> Hi,
>>>>
>>>> Currently, TLV related protocol is not shared to user land. This is not
>>>> good in a point of application interfaces, because application developers
>>>> can't realize the protocol just to see UAPI headers.
>>>>
>>>> For this purpose, this patchset moves all of macros related to TLV to UAPI
>>>> header. As a result, a header just for kernel land is obsoleted. When
>>>> adding
>>>> new items to the protocol, it's added to the UAPI header. This change
>>>> affects
>>>> some drivers in media subsystem.
>>>>
>>>> In my concern, this change can break applications. When these macros are
>>>> already defined in application side and they includes tlv UAPI header
>>>> directly, 'redefined' warning is generated at preprocess time. But the
>>>> compilation will be success itself. If these two macros have different
>>>> content, the result of preprocess is dominated to the order to define.
>>>> However, the most applications are assumed to use TLV feature via libraries
>>>> such as alsa-lib, thus I'm optimistic to this concern.
>>>>
>>>> As another my concern, the name of these macros are quite simple, as
>>>> 'TLV_XXX'. It might be help application developers to rename them with a
>>>> prefix, as 'SNDRV_CTL_TLV_XXX'. (But not yet. I'm a lazy guy.)
>>>
>>> The second patch does simply wrong. You must not obsolete
>>> include/sound/tlv.h. Even if it includes only uapi/*, it should be
>>> still there.
>>
>> Any reasons?
>
> The concept and the design.
>
> Don't need to change the root inclusion, it's just to provide cleaner
> uapi header files, and not meant to be included directly -- it was the
> basic idea when uapi split was introduced.
OK. I can see what you indicated in this post for UAPI idea[0]. I'm
ready to drop the second patch.
Well, how do you think about my concern of macro prefix? For example, we
can apply below step:
Put substantial macros with renaming to 'include/uapi.sound/tlv.h':
#define SNDRV_CTL_TLV_DATA_LENGTH(...) \
((unsigned int)sizeof((const unsigned int[]) { __VA_ARGS__ }))
Then, put alias macros to 'include/sound/tlv.h':
#include
#define TLV_LENGTH SNDRV_CTL_TLV_DATA_LENGTH
...
Finally, applications can expand these macro with apparent names with
prefix of 'SNDRV_CTL_TLV_DATA_XXX'. I think the prefix prevent
application codes from name conflict by including 'uapi/sound/tlv.h'.
Thanks
[0] [PATCH 00/13] UAPI header file split
https://lkml.org/lkml/2012/7/20/406
Takashi Sakamoto
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 0/2] ALSA: control: export all of TLV related macros to user land
On Sep 10 2016 15:44, Takashi Iwai wrote: > On Sat, 10 Sep 2016 06:50:14 +0200, > Takashi Sakamoto wrote: >> >> Hi, >> >> Currently, TLV related protocol is not shared to user land. This is not >> good in a point of application interfaces, because application developers >> can't realize the protocol just to see UAPI headers. >> >> For this purpose, this patchset moves all of macros related to TLV to UAPI >> header. As a result, a header just for kernel land is obsoleted. When adding >> new items to the protocol, it's added to the UAPI header. This change affects >> some drivers in media subsystem. >> >> In my concern, this change can break applications. When these macros are >> already defined in application side and they includes tlv UAPI header >> directly, 'redefined' warning is generated at preprocess time. But the >> compilation will be success itself. If these two macros have different >> content, the result of preprocess is dominated to the order to define. >> However, the most applications are assumed to use TLV feature via libraries >> such as alsa-lib, thus I'm optimistic to this concern. >> >> As another my concern, the name of these macros are quite simple, as >> 'TLV_XXX'. It might be help application developers to rename them with a >> prefix, as 'SNDRV_CTL_TLV_XXX'. (But not yet. I'm a lazy guy.) > > The second patch does simply wrong. You must not obsolete > include/sound/tlv.h. Even if it includes only uapi/*, it should be > still there. Any reasons? > So, just move the stuff to include/uapi/sound/tlv.h, and that's all. Regards Takashi Sakamoto -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][PATCH 0/2] ALSA: control: export all of TLV related macros to user land
Hi, Currently, TLV related protocol is not shared to user land. This is not good in a point of application interfaces, because application developers can't realize the protocol just to see UAPI headers. For this purpose, this patchset moves all of macros related to TLV to UAPI header. As a result, a header just for kernel land is obsoleted. When adding new items to the protocol, it's added to the UAPI header. This change affects some drivers in media subsystem. In my concern, this change can break applications. When these macros are already defined in application side and they includes tlv UAPI header directly, 'redefined' warning is generated at preprocess time. But the compilation will be success itself. If these two macros have different content, the result of preprocess is dominated to the order to define. However, the most applications are assumed to use TLV feature via libraries such as alsa-lib, thus I'm optimistic to this concern. As another my concern, the name of these macros are quite simple, as 'TLV_XXX'. It might be help application developers to rename them with a prefix, as 'SNDRV_CTL_TLV_XXX'. (But not yet. I'm a lazy guy.) Takashi Sakamoto (2): ALSA: control: export layout of TLV payload to UAPI header ALSA: control: replace include statements for TLV Documentation/DocBook/writing-an-alsa-driver.tmpl | 2 +- Documentation/sound/alsa/Channel-Mapping-API.txt | 2 +- drivers/media/pci/cx18/cx18-alsa-mixer.c | 2 +- drivers/media/pci/cx23885/cx23885-alsa.c | 2 +- drivers/media/pci/cx25821/cx25821-alsa.c | 2 +- drivers/media/pci/cx88/cx88-alsa.c| 2 +- drivers/media/pci/ivtv/ivtv-alsa-mixer.c | 2 +- drivers/media/usb/em28xx/em28xx-audio.c | 2 +- include/sound/tlv.h | 62 +-- include/uapi/sound/tlv.h | 60 ++ sound/core/pcm_lib.c | 2 +- sound/core/vmaster.c | 2 +- sound/drivers/dummy.c | 2 +- sound/drivers/vx/vx_mixer.c | 2 +- sound/firewire/isight.c | 2 +- sound/hda/hdmi_chmap.c| 2 +- sound/i2c/other/ak4xxx-adda.c | 2 +- sound/i2c/other/pt2258.c | 2 +- sound/isa/ad1816a/ad1816a_lib.c | 2 +- sound/isa/cs423x/cs4236_lib.c | 2 +- sound/isa/opl3sa2.c | 2 +- sound/isa/opti9xx/opti92x-ad1848.c| 2 +- sound/isa/wss/wss_lib.c | 2 +- sound/pci/ac97/ac97_codec.c | 2 +- sound/pci/ak4531_codec.c | 2 +- sound/pci/asihpi/asihpi.c | 2 +- sound/pci/au88x0/au88x0.h | 2 +- sound/pci/ca0106/ca0106_mixer.c | 2 +- sound/pci/cs4281.c| 2 +- sound/pci/ctxfi/ctmixer.c | 2 +- sound/pci/echoaudio/darla20.c | 2 +- sound/pci/echoaudio/darla24.c | 2 +- sound/pci/echoaudio/echo3g.c | 2 +- sound/pci/echoaudio/gina20.c | 2 +- sound/pci/echoaudio/gina24.c | 2 +- sound/pci/echoaudio/indigo.c | 2 +- sound/pci/echoaudio/indigodj.c| 2 +- sound/pci/echoaudio/indigodjx.c | 2 +- sound/pci/echoaudio/indigoio.c| 2 +- sound/pci/echoaudio/indigoiox.c | 2 +- sound/pci/echoaudio/layla20.c | 2 +- sound/pci/echoaudio/layla24.c | 2 +- sound/pci/echoaudio/mia.c | 2 +- sound/pci/echoaudio/mona.c| 2 +- sound/pci/emu10k1/emufx.c | 2 +- sound/pci/emu10k1/emumixer.c | 2 +- sound/pci/emu10k1/p16v.c | 2 +- sound/pci/es1938.c| 2 +- sound/pci/fm801.c | 2 +- sound/pci/hda/hda_codec.c | 2 +- sound/pci/hda/hda_generic.c | 2 +- sound/pci/hda/patch_cirrus.c | 2 +- sound/pci/hda/patch_hdmi.c| 2 +- sound/pci/ice1712/aureon.c| 2 +- sound/pci/ice1712/ice1712.c | 2 +- sound/pci/ice1712/juli.c | 2 +- sound/pci/ice1712/maya44.c| 2 +- sound/pci/ice1712/phase.c | 2 +- sound/pci/ice1712/pontis.c| 2 +- sound/pci/ice1712/prodigy192.c| 2 +- sound/pci/ice1712/prodigy_hifi.c | 2 +- sound/pci/ice1712/quartet.c | 2
[RFC][PATCH 1/2] ALSA: control: export layout of TLV payload to UAPI header
In ALSA control interface, each element set can have threshold level
information. This information is transferred between drivers/applications,
in a shape of tlv packet. The layout of this packet is defined in
'uapi/sound/asound.h' (struct snd_ctl_tlv):
struct snd_ctl_tlv {
unsigned int numid;
unsigned int length;
unsigned int tlv[0];
};
Data in the payload (struct snd_ctl_tlv.tlv) is expected to be filled
according to our own protocol. This protocol is described in
'include/sound/tlv.h'. A layout of the payload is expected as:
struct snd_ctl_tlv.tlv[0]: one of SNDRV_CTL_TLVT_XXX
struct snd_ctl_tlv.tlv[1]: Length of data
struct snd_ctl_tlv.tlv[2...]: data
Unfortunately, the macro is not exported to user land yet, thus
applications cannot get to know the protocol.
Additionally, ALSA control core has a feature called as 'user-defined'
element set. This allows applications to add/remove arbitrary element sets
with elements to control devices. Elements in the element set can be
operated by the same way as the ones added by in-kernel implementation.
For threshold level information of 'user-defined' element set, applications
need to register the information to an element set. However, as described
above, layout of the payload is closed in kernel land. This is quite
inconvenient, too.
This commit moves the protocol to UAPI header for TLV. According to this
change, an old header is obsoleted.
Signed-off-by: Takashi Sakamoto <o-taka...@sakamocchi.jp>
---
include/sound/tlv.h | 62 +---
include/uapi/sound/tlv.h | 60 ++
2 files changed, 61 insertions(+), 61 deletions(-)
diff --git a/include/sound/tlv.h b/include/sound/tlv.h
index df97d19..7b0d0d1 100644
--- a/include/sound/tlv.h
+++ b/include/sound/tlv.h
@@ -22,67 +22,7 @@
*
*/
-/*
- * TLV structure is right behind the struct snd_ctl_tlv:
- * unsigned int type - see SNDRV_CTL_TLVT_*
- * unsigned int length
- * data aligned to sizeof(unsigned int), use
- *block_length = (length + (sizeof(unsigned int) - 1)) &
- * ~(sizeof(unsigned int) - 1))
- */
-
+/* You should include UAPI header directly, instead of this. */
#include
-#define TLV_ITEM(type, ...) \
- (type), TLV_LENGTH(__VA_ARGS__), __VA_ARGS__
-#define TLV_LENGTH(...) \
- ((unsigned int)sizeof((const unsigned int[]) { __VA_ARGS__ }))
-
-#define TLV_CONTAINER_ITEM(...) \
- TLV_ITEM(SNDRV_CTL_TLVT_CONTAINER, __VA_ARGS__)
-#define DECLARE_TLV_CONTAINER(name, ...) \
- unsigned int name[] = { TLV_CONTAINER_ITEM(__VA_ARGS__) }
-
-#define TLV_DB_SCALE_MASK 0x
-#define TLV_DB_SCALE_MUTE 0x1
-#define TLV_DB_SCALE_ITEM(min, step, mute) \
- TLV_ITEM(SNDRV_CTL_TLVT_DB_SCALE, \
-(min), \
-((step) & TLV_DB_SCALE_MASK) | \
- ((mute) ? TLV_DB_SCALE_MUTE : 0))
-#define DECLARE_TLV_DB_SCALE(name, min, step, mute) \
- unsigned int name[] = { TLV_DB_SCALE_ITEM(min, step, mute) }
-
-/* dB scale specified with min/max values instead of step */
-#define TLV_DB_MINMAX_ITEM(min_dB, max_dB) \
- TLV_ITEM(SNDRV_CTL_TLVT_DB_MINMAX, (min_dB), (max_dB))
-#define TLV_DB_MINMAX_MUTE_ITEM(min_dB, max_dB)\
- TLV_ITEM(SNDRV_CTL_TLVT_DB_MINMAX_MUTE, (min_dB), (max_dB))
-#define DECLARE_TLV_DB_MINMAX(name, min_dB, max_dB) \
- unsigned int name[] = { TLV_DB_MINMAX_ITEM(min_dB, max_dB) }
-#define DECLARE_TLV_DB_MINMAX_MUTE(name, min_dB, max_dB) \
- unsigned int name[] = { TLV_DB_MINMAX_MUTE_ITEM(min_dB, max_dB) }
-
-/* linear volume between min_dB and max_dB (.01dB unit) */
-#define TLV_DB_LINEAR_ITEM(min_dB, max_dB) \
- TLV_ITEM(SNDRV_CTL_TLVT_DB_LINEAR, (min_dB), (max_dB))
-#define DECLARE_TLV_DB_LINEAR(name, min_dB, max_dB)\
- unsigned int name[] = { TLV_DB_LINEAR_ITEM(min_dB, max_dB) }
-
-/* dB range container:
- * Items in dB range container must be ordered by their values and by their
- * dB values. This implies that larger values must correspond with larger
- * dB values (which is also required for all other mixer controls).
- */
-/* Each item is:*/
-#define TLV_DB_RANGE_ITEM(...) \
- TLV_ITEM(SNDRV_CTL_TLVT_DB_RANGE, __VA_ARGS__)
-#define DECLARE_TLV_DB_RANGE(name, ...) \
- unsigned int name[] = { TLV_DB_RANGE_ITEM(__VA_ARGS__) }
-/* The below assumes that each item TLV is 4 words like DB_SCALE or LINEAR */
-#define TLV_DB_RANGE_HEAD(num) \
- SNDRV_CTL_TLVT_DB_RANGE, 6 * (num) * sizeof(unsigned int)
-
-#define TLV_DB_GAIN_MUTE -999
-
#endif /* __SOUND_TLV_H */
diff --git a/include/uapi/sound/tlv.h b/include/uapi/sound/tlv.h
index ffc4f20..b741e0e 100644
--- a/include/uapi/sound/tlv.h
+++ b/include/uapi/sound/tlv.h
@
[RFC][PATCH 2/2] ALSA: control: replace include statements for UAPI TLV header
A former commit moves all of macros related TLV to UAPI header and obsoletes a header for TLV just for kernel land. The aim is to share TLV packet protocol to user land. This commit changes codes to include it tree-widely. Although the obsoleted header still remains for out-of-tree drivers, the drivers should be changed as soon as possible, because the header might be removed in future release. Signed-off-by: Takashi Sakamoto <o-taka...@sakamocchi.jp> --- Documentation/DocBook/writing-an-alsa-driver.tmpl | 2 +- Documentation/sound/alsa/Channel-Mapping-API.txt | 2 +- drivers/media/pci/cx18/cx18-alsa-mixer.c | 2 +- drivers/media/pci/cx23885/cx23885-alsa.c | 2 +- drivers/media/pci/cx25821/cx25821-alsa.c | 2 +- drivers/media/pci/cx88/cx88-alsa.c| 2 +- drivers/media/pci/ivtv/ivtv-alsa-mixer.c | 2 +- drivers/media/usb/em28xx/em28xx-audio.c | 2 +- sound/core/pcm_lib.c | 2 +- sound/core/vmaster.c | 2 +- sound/drivers/dummy.c | 2 +- sound/drivers/vx/vx_mixer.c | 2 +- sound/firewire/isight.c | 2 +- sound/hda/hdmi_chmap.c| 2 +- sound/i2c/other/ak4xxx-adda.c | 2 +- sound/i2c/other/pt2258.c | 2 +- sound/isa/ad1816a/ad1816a_lib.c | 2 +- sound/isa/cs423x/cs4236_lib.c | 2 +- sound/isa/opl3sa2.c | 2 +- sound/isa/opti9xx/opti92x-ad1848.c| 2 +- sound/isa/wss/wss_lib.c | 2 +- sound/pci/ac97/ac97_codec.c | 2 +- sound/pci/ak4531_codec.c | 2 +- sound/pci/asihpi/asihpi.c | 2 +- sound/pci/au88x0/au88x0.h | 2 +- sound/pci/ca0106/ca0106_mixer.c | 2 +- sound/pci/cs4281.c| 2 +- sound/pci/ctxfi/ctmixer.c | 2 +- sound/pci/echoaudio/darla20.c | 2 +- sound/pci/echoaudio/darla24.c | 2 +- sound/pci/echoaudio/echo3g.c | 2 +- sound/pci/echoaudio/gina20.c | 2 +- sound/pci/echoaudio/gina24.c | 2 +- sound/pci/echoaudio/indigo.c | 2 +- sound/pci/echoaudio/indigodj.c| 2 +- sound/pci/echoaudio/indigodjx.c | 2 +- sound/pci/echoaudio/indigoio.c| 2 +- sound/pci/echoaudio/indigoiox.c | 2 +- sound/pci/echoaudio/layla20.c | 2 +- sound/pci/echoaudio/layla24.c | 2 +- sound/pci/echoaudio/mia.c | 2 +- sound/pci/echoaudio/mona.c| 2 +- sound/pci/emu10k1/emufx.c | 2 +- sound/pci/emu10k1/emumixer.c | 2 +- sound/pci/emu10k1/p16v.c | 2 +- sound/pci/es1938.c| 2 +- sound/pci/fm801.c | 2 +- sound/pci/hda/hda_codec.c | 2 +- sound/pci/hda/hda_generic.c | 2 +- sound/pci/hda/patch_cirrus.c | 2 +- sound/pci/hda/patch_hdmi.c| 2 +- sound/pci/ice1712/aureon.c| 2 +- sound/pci/ice1712/ice1712.c | 2 +- sound/pci/ice1712/juli.c | 2 +- sound/pci/ice1712/maya44.c| 2 +- sound/pci/ice1712/phase.c | 2 +- sound/pci/ice1712/pontis.c| 2 +- sound/pci/ice1712/prodigy192.c| 2 +- sound/pci/ice1712/prodigy_hifi.c | 2 +- sound/pci/ice1712/quartet.c | 2 +- sound/pci/ice1712/se.c| 2 +- sound/pci/ice1712/wm8766.c| 2 +- sound/pci/ice1712/wm8776.c| 2 +- sound/pci/ice1712/wtm.c | 2 +- sound/pci/lola/lola_mixer.c | 2 +- sound/pci/mixart/mixart_mixer.c | 2 +- sound/pci/oxygen/oxygen.c | 2 +- sound/pci/oxygen/oxygen_mixer.c | 2 +- sound/pci/oxygen/xonar_cs43xx.c | 2 +- sound/pci/oxygen/xonar_dg.c | 2 +- sound/pci/oxygen/xonar_dg_mixer.c | 2 +- sound/pci/oxygen/xonar_hdmi.c | 2 +- sound/pci/oxygen/xonar_pcm179x.c | 2 +- sound/pci/oxygen/xonar_wm87x6.c | 2 +- sound/pci/pcxhr/pcxhr_mix22.c | 2 +- sound/pci/pcxhr/pcxhr_mixer.c | 2 +- sound/pci/trident/trident_main.c | 2 +- sound/pci/via82xx.c | 2 +- sou
Re: [very-RFC 0/8] TSN driver for the kernel
On 2016年06月20日 18:06, Henrik Austad wrote: On Sun, Jun 19, 2016 at 11:45:47PM +0900, Takashi Sakamoto wrote: (remove C.C. to lkml. This is not so major feature.) On Jun 19 2916 07:45, Henrik Austad wrote: snip 802.1Q gives you low latency through the network, but more importantly, no dropped frames. gPTP gives you a central reference to time. When such a long message is required, it means that we don't have enough premises for this discussion. Isn't a discussion part of how information is conveyed and finding parts that require more knowledge? You have just interests in gPTP and transferring AVTPDUs, while no interests in the others such as "what the basic ideas of TSN come from" and "the reason that IEEE 1722 refers to IEC 61883 series which is originally designed for IEEE 1394 bus" and "the reason that I was motivated to join in this discussion even though not a netdev developer". I'm sorry, I'm not sure I follow you here. What do you mean I don't have any interest in where TSN comes from? or the reason why 1722 use IEC 61883? What about "they picked 61883 because it made sense?" gPTP itself is *not* about transffering audio-data, it is about agreeing on a common time so that when you *do* transfer audio-data, the samplerate actually means something. Let me ask you this; if you have 2 sound-cards in your computer and you want to attach a mic to one and speakers to the other, how do you solve streaming of audio from the mic to the speaker If you answer does not contain something akin to "different timing-domain issues", I'd be very surprised. If you are interested in TSN for transferring *anything*, _including_ audio, you *have* to take gPTP into consideration. Just as you have to think about stream reservation, compliant hardware and all the different subsystems you are going to run into, either via kernel or via userspace. Here, could I ask you a question? Do you know a role of cycle start packet of IEEE Std 1394? No, I do not. I have only passing knowledge of the firewire standard, I've looked at the encoding described in 1722 and added that to the alsa shim as an example of how to use TSN. As I stated, this was a *very* early version and I would like to use TSN for audio - and more work is needed. If you think it's not related to this discussion, please tell it to me. Then I'll drop out from this thread. There are tons of details left and right, and as I said, I'm not all to familiar with firewire. I know that one of the authors behind the firewire standard happened to be part of 1722 standard. I am currently working my way through the firewire-stak paper you've written, and I have gotten a lot of pointers to other areas I need to dig into so I should be busy for a while. That being said, Richard's point about a way to find sample-rate of a hardware device and ways to influence that, is important for AVB/TSN. History Repeats itself. ? OK. Bye. Takashi Sakamoto -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [very-RFC 0/8] TSN driver for the kernel
(remove C.C. to lkml. This is not so major feature.) On Jun 19 2916 07:45, Henrik Austad wrote: snip 802.1Q gives you low latency through the network, but more importantly, no dropped frames. gPTP gives you a central reference to time. When such a long message is required, it means that we don't have enough premises for this discussion. You have just interests in gPTP and transferring AVTPDUs, while no interests in the others such as "what the basic ideas of TSN come from" and "the reason that IEEE 1722 refers to IEC 61883 series which is originally designed for IEEE 1394 bus" and "the reason that I was motivated to join in this discussion even though not a netdev developer". Here, could I ask you a question? Do you know a role of cycle start packet of IEEE Std 1394? If you think it's not related to this discussion, please tell it to me. Then I'll drop out from this thread. History Repeats itself. Takashi Sakamoto -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [very-RFC 0/8] TSN driver for the kernel
Hi, Sorry to be late. In this weekday, I have little time for this thread because working for alsa-lib[1]. Besides, I'm not full-time developer for this kind of work. In short, I use my limited private time for this discussion. On Jun 15 2016 17:06, Richard Cochran wrote: > On Wed, Jun 15, 2016 at 12:15:24PM +0900, Takashi Sakamoto wrote: >>> On Mon, Jun 13, 2016 at 01:47:13PM +0200, Richard Cochran wrote: >>>> I have seen audio PLL/multiplier chips that will take, for example, a >>>> 10 kHz input and produce your 48 kHz media clock. With the right HW >>>> design, you can tell your PTP Hardware Clock to produce a 1 PPS, >>>> and you will have a synchronized AVB endpoint. The software is all >>>> there already. Somebody should tell the ALSA guys about it. >> >> Just from my curiosity, could I ask you more explanation for it in ALSA >> side? > > (Disclaimer: I really don't know too much about ALSA, expect that is > fairly big and complex ;) In this morning, I read IEEE 1722:2011 and realized that it quite roughly refers to IEC 61883-1/6 and includes much ambiguities to end applications. (In my opinion, the author just focuses on packet with timestamps, without enough considering about how to implement endpoint applications which perform semi-real sampling, fetching and queueing and so on, so as you. They're satisfied just by handling packet with timestamp, without enough consideration about actual hardware/software applications.) > Here is what I think ALSA should provide: > > - The DA and AD clocks should appear as attributes of the HW device. > > - There should be a method for measuring the DA/AD clock rate with > respect to both the system time and the PTP Hardware Clock (PHC) > time. > > - There should be a method for adjusting the DA/AD clock rate if > possible. If not, then ALSA should fall back to sample rate > conversion. > > - There should be a method to determine the time delay from the point > when the audio data are enqueued into ALSA until they pass through > the D/A converter. If this cannot be known precisely, then the > library should provide an estimate with an error bound. > > - I think some AVB use cases will need to know the time delay from A/D > until the data are available to the local application. (Distributed > microphones? I'm not too sure about that.) > > - If the DA/AD clocks are connected to other clock devices in HW, > there should be a way to find this out in SW. For example, if SW > can see the PTP-PHC-PLL-DA relationship from the above example, then > it knows how to synchronize the DA clock using the network. > > [ Implementing this point involves other subsystems beyond ALSA. It > isn't really necessary for people designing AVB systems, since > they know their designs, but it would be nice to have for writing > generic applications that can deal with any kind of HW setup. ] Depends on which subsystem decides "AVTP presentation time"[3]. This value is dominant to the number of events included in an IEC 61883-1 packet. If this TSN subsystem decides it, most of these items don't need to be in ALSA. As long as I know, the number of AVTPDU per second seems not to be fixed. So each application is not allowed to calculate the timestamp by its own way unless TSN implementation gives the information to each applications. For your information, in current ALSA implementation of IEC 61883-1/6 on IEEE 1394 bus, the presentation timestamp is decided in ALSA side. The number of isochronous packet transmitted per second is fixed by 8,000 in IEEE 1394, and the number of data blocks in an IEC 61883-1 packet is deterministic according to 'sampling transfer frequency' in IEC 61883-6 and isochronous cycle count passed from Linux FireWire subsystem. In the TSN subsystem, like FireWire subsystem, callback for filling payload should have information of 'when the packet is scheduled to be transmitted'. With the information, each application can calculate the number of event in the packet and presentation timestamp. Of cource, this timestamp should be handled as 'avtp_timestamp' in packet queueing. >> In ALSA, sampling rate conversion should be in userspace, not in kernel >> land. In alsa-lib, sampling rate conversion is implemented in shared object. >> When userspace applications start playbacking/capturing, depending on PCM >> node to access, these applications load the shared object and convert PCM >> frames from buffer in userspace to mmapped DMA-buffer, then commit them. > > The AVB use case places an additional requirement on the rate > conversion. You will need to adjust the frequency on the fly, as the > stream is playing. I would guess that ALSA doesn't have that option? In ALSA
Re: [very-RFC 0/8] TSN driver for the kernel
Hi Richard, On Tue, 14 Jun 2016 19:04:44 +0200, Richard Cochran write: >> Well, I guess I should have said, I am not too familiar with the >> breadth of current audio hardware, high end or low end. Of course I >> would like to see even consumer devices work with AVB, but it is up to >> the ALSA people to make that happen. So far, nothing has been done, >> afaict. In OSS world, there's few developers for this kind of devices, even if it's alsa-project. Furthermore, manufacturerer for recording equipments have no interests in OSS. In short, what we can do for these devices is just to reverse-engineering. For models of Ethernet-AVB, it might be just to transfer or receive packets, and read them. The devices are still black-boxes and we have no ways to reveal their details. So when you require the details to implement something in your side, few developers can tell you, I think. Regards Takashi Sakamoto -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [very-RFC 0/8] TSN driver for the kernel
Hi Richard, > On Mon, Jun 13, 2016 at 01:47:13PM +0200, Richard Cochran wrote: >> 3. ALSA support for tunable AD/DA clocks. The rate of the Listener's >>DA clock must match that of the Talker and the other Listeners. >>Either you adjust it in HW using a VCO or similar, or you do >>adaptive sample rate conversion in the application. (And that is >>another reason for *not* having a shared kernel buffer.) For the >>Talker, either you adjust the AD clock to match the PTP time, or >>you measure the frequency offset. >> >> I have seen audio PLL/multiplier chips that will take, for example, a >> 10 kHz input and produce your 48 kHz media clock. With the right HW >> design, you can tell your PTP Hardware Clock to produce a 1 PPS, >> and you will have a synchronized AVB endpoint. The software is all >> there already. Somebody should tell the ALSA guys about it. Just from my curiosity, could I ask you more explanation for it in ALSA side? The similar mechanism to synchronize endpoints was also applied to audio and music unit on IEEE 1394 bus. According to IEC 61883-1/6, some of these actual units can generate presentation-timestamp from header information of 8,000 packet per sec, and utilize the signal as sampling clock[1]. There's much differences between IEC 61883-1/6 on IEEE 1394 bus and Audio and Video Bridge on Ethernet[2], especially for synchronization, but in this point of transferring synchnization signal and time-based data, we have the similar requirements of software implementations, I think. My motivation to join in this discussion is to consider about to make it clear to implement packet-oriented drivers in ALSA kernel-land, and enhance my work for drivers to handle IEC 61883-1/6 on IEEE 1394 bus. >> I don't know if ALSA has anything for sample rate conversion or not, >> but haven't seen anything that addresses distributed synchronized >> audio applications. In ALSA, sampling rate conversion should be in userspace, not in kernel land. In alsa-lib, sampling rate conversion is implemented in shared object. When userspace applications start playbacking/capturing, depending on PCM node to access, these applications load the shared object and convert PCM frames from buffer in userspace to mmapped DMA-buffer, then commit them. Before establishing a PCM substream, userspace applications and in-kernel drivers communicate to decide sampling rate, PCM frame format, the size of PCM buffer, and so on. (see snd_pcm_hw_params() and ioctl(SNDRV_PCM_IOCTL_HW_PARAMS)). Thus, as long as in-kernel drivers know specifications of endpoints, userspace applications can start PCM substreams correctly. [1] In detail, please refer to specification of 1394TA I introduced: http://www.spinics.net/lists/netdev/msg381259.html [2] I guess that IEC 61883-1/6 packet for Ethernet-AVB is a mutant from original specifications. Regards Takashi Sakamoto -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [very-RFC 0/8] TSN driver for the kernel
On Jun 12 2016 17:31, Henrik Austad wrote: > On Sun, Jun 12, 2016 at 01:30:24PM +0900, Takashi Sakamoto wrote: >> On Jun 12 2016 12:38, Takashi Sakamoto wrote: >>> In your patcset, there's no actual codes about how to handle any >>> interrupt contexts (software / hardware), how to handle packet payload, >>> and so on. Especially, for recent sound subsystem, the timing of >>> generating interrupts and which context does what works are important to >>> reduce playback/capture latency and power consumption. >>> >>> Of source, your intention of this patchset is to show your early concept >>> of TSN feature. Nevertheless, both of explaination and codes are >>> important to the other developers who have little knowledges about TSN, >>> AVB and AES-64 such as me. >> >> Oops. Your 5th patch was skipped by alsa-project.org. I guess that size >> of the patch is too large to the list service. I can see it: >> http://marc.info/?l=linux-netdev=146568672728661=2 >> >> As long as seeing the patch, packets are queueing in hrtimer callbacks >> every 1 seconds. > > Actually, the hrtimer fires every 1ms, and that part is something I have to > do something about, also because it sends of the same number of frames > every time, regardless of how accurate the internal timer is to the rest of > the network (there's no backpressure from the networking layer). > >> (This is a high level discussion and it's OK to ignore it for the >> moment. When writing packet-oriented drivers for sound subsystem, you >> need to pay special attention to accuracy of the number of PCM frames >> transferred currently, and granularity of the number of PCM frames >> transferred by one operation. In this case, snd_avb_hw, >> snd_avb_pcm_pointer(), tsn_buffer_write_net() and tsn_buffer_read_net() >> are involved in this discussion. You can see ALSA developers' struggle >> in USB audio device class drivers and (of cource) IEC 61883-1/6 drivers.) > > Ah, good point. Any particular parts of the USB-subsystem I should start > looking at? I don't think it's a beter way for you to study USB Audio Device Class driver unless you're interested in ALSA or USB subsystem. (But for your information, snd-usb-audio is in sound/usb/* of Linux kernel. IEC 61883-1/6 driver is in sound/firewire/*.) We need different strategy to achieve it on different transmission backend. > Knowing where to start looking is a tremendous help It's not well-documented, and not well-generalized for packet-oriented drivers. Most of developers who have enough knowledge about it work for DMA-oriented drivers in mobile platforms and have little interests in packet-oriented drivers. You need to find your own way. Currently I have few advices to you, because I'm also on the way for drivers to process IEC 61883-1/6 packets on IEEE 1394 bus with enough accuracy and granularity. The paper I introduced is for the way (but not mature). I wish you get more helps from the other developers. Your work is more significant to Linux system, than mine. (And I hope your future work get no ignorance and no unreasonable hostility from coarse users.) Regards Takashi Sakamoto signature.asc Description: OpenPGP digital signature
Re: [very-RFC 0/8] TSN driver for the kernel
On Jun 12 2016 17:28, Henrik Austad wrote: > On Sun, Jun 12, 2016 at 12:38:36PM +0900, Takashi Sakamoto wrote: >> I'm one of maintainers for ALSA firewire stack, which handles IEC >> 61883-1/6 and vendor-unique packets on IEEE 1394 bus for consumer >> recording equipments. >> (I'm not in MAINTAINERS because I'm a shy boy.) >> >> IEC 61883-6 describes that one packet can multiplex several types of >> data in its data channels; i.e. Multi Bit Linear Audio data (PCM >> samples), One Bit Audio Data (DSD), MIDI messages and so on. > > Hmm, that I did not know, not sure how that applies to AVB, but definately > something I have to look into. For your information, I describe more about it. You can see pre-standardized specification for IEC 61883-6 in website of 1394 Trade Association. Let's look for 'Audio and Music Data Transmission Protocol 2.3 (October 13, 2010, 1394TA)' http://1394ta.org/specifications/ In 'clause 12. AM824 SEQUENCE ADAPTATION LAYERS', you can see that one data block includes several types of data. But I can imagine that joint group for AVB loosely refers to IEC 61883-6. In this case, AVB specification might describe one data block transfers one type of data, to drop unreasonable complexities. >> If you handles packet payload in 'struct snd_pcm_ops.copy', a process >> context of an ALSA PCM applications performs the work. Thus, no chances >> to multiplex data with the other types. > > The driver is not adhering fully to any standards right now, the amount of > detail is quite high - but I'm slowly improving as I go through the > standards. Getting on top of all the standards and all the different > subsystems are definately a work in progress (it's a lot to digest!) In my taste, the driver is not necessarily compliant to any standards. It's enough just to work its task, without bad side-effects to Linux system. Based on this concept, current ALSA firewire stack just support PCM frames and MIDI messages. Here, I tell you that actual devices tend not to be compliant to any standards and lost inter-operability. (Especially, most of audio and music units on IEEE 1394 bus ignores some of items in standards. In short, they already lost inter-operability.) So here, we just consider about what actual devices do, instead of following any standards. Regards Takashi Sakamoto signature.asc Description: OpenPGP digital signature
Re: [very-RFC 0/8] TSN driver for the kernel
On Jun 12 2016 12:38, Takashi Sakamoto wrote: > In your patcset, there's no actual codes about how to handle any > interrupt contexts (software / hardware), how to handle packet payload, > and so on. Especially, for recent sound subsystem, the timing of > generating interrupts and which context does what works are important to > reduce playback/capture latency and power consumption. > > Of source, your intention of this patchset is to show your early concept > of TSN feature. Nevertheless, both of explaination and codes are > important to the other developers who have little knowledges about TSN, > AVB and AES-64 such as me. Oops. Your 5th patch was skipped by alsa-project.org. I guess that size of the patch is too large to the list service. I can see it: http://marc.info/?l=linux-netdev=146568672728661=2 As long as seeing the patch, packets are queueing in hrtimer callbacks every 1 seconds. (This is a high level discussion and it's OK to ignore it for the moment. When writing packet-oriented drivers for sound subsystem, you need to pay special attention to accuracy of the number of PCM frames transferred currently, and granularity of the number of PCM frames transferred by one operation. In this case, snd_avb_hw, snd_avb_pcm_pointer(), tsn_buffer_write_net() and tsn_buffer_read_net() are involved in this discussion. You can see ALSA developers' struggle in USB audio device class drivers and (of cource) IEC 61883-1/6 drivers.) Regards Takashi Sakamoto -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [very-RFC 0/8] TSN driver for the kernel
Hi, I'm one of maintainers for ALSA firewire stack, which handles IEC 61883-1/6 and vendor-unique packets on IEEE 1394 bus for consumer recording equipments. (I'm not in MAINTAINERS because I'm a shy boy.) IEC 61883-6 describes that one packet can multiplex several types of data in its data channels; i.e. Multi Bit Linear Audio data (PCM samples), One Bit Audio Data (DSD), MIDI messages and so on. If you handles packet payload in 'struct snd_pcm_ops.copy', a process context of an ALSA PCM applications performs the work. Thus, no chances to multiplex data with the other types. To prevent this situation, current ALSA firewire stack handles packet payload in software interrupt context of isochronous context of OHCI 1394. As a result of this, the software stack supports PCM substreams and MIDI substreams. In your patcset, there's no actual codes about how to handle any interrupt contexts (software / hardware), how to handle packet payload, and so on. Especially, for recent sound subsystem, the timing of generating interrupts and which context does what works are important to reduce playback/capture latency and power consumption. Of source, your intention of this patchset is to show your early concept of TSN feature. Nevertheless, both of explaination and codes are important to the other developers who have little knowledges about TSN, AVB and AES-64 such as me. And, I might cooperate to prepare for common IEC 61883 layer. For actual codes of ALSA firewire stack, please see mainline kernel code. For actual devices of IEC 61883-1/6 and IEEE 1394 bus, please refer to my report in 2014. At least, you can get to know what to consider about developing upper drivers near ALSA userspace applications. https://github.com/takaswie/alsa-firewire-report (But I confirm that the report includes my misunderstandings in clause 3.4 and 6.2. need more time...) Regards Takashi Sakamoto On Jun 12 2016 08:01, Henrik Austad wrote: > Hi all > (series based on v4.7-rc2, now with the correct netdev) > > This is a *very* early RFC for a TSN-driver in the kernel. It has been > floating around in my repo for a while and I would appreciate some > feedback on the overall design to avoid doing some major blunders. > > TSN: Time Sensitive Networking, formely known as AVB (Audio/Video > Bridging). > > There are at least one AVB-driver (the AV-part of TSN) in the kernel > already, however this driver aims to solve a wider scope as TSN can do > much more than just audio. A very basic ALSA-driver is added to the end > that allows you to play music between 2 machines using aplay in one end > and arecord | aplay on the other (some fiddling required) We have plans > for doing the same for v4l2 eventually (but there are other fishes to > fry first). The same goes for a TSN_SOCK type approach as well. > > TSN is all about providing infrastructure. Allthough there are a few > very interesting uses for TSN (reliable, deterministic network for audio > and video), once you have that reliable link, you can do a lot more. > > Some notes on the design: > > The driver is directed via ConfigFS as we need userspace to handle > stream-reservation (MSRP), discovery and enumeration (IEEE 1722.1) and > whatever other management is needed. Once we have all the required > attributes, we can create link using mkdir, and use write() to set the > attributes. Once ready, specify the 'shim' (basically a thin wrapper > between TSN and another subsystem) and we start pushing out frames. > > The network part: it ties directly into the rx-handler for receive and > writes skb's using netdev_start_xmit(). This could probably be > improved. 2 new fields in netdev_ops have been introduced, and the Intel > igb-driver has been updated (as this is available as a PCI-e card). The > igb-driver works-ish > > > What remains > - tie to (g)PTP properly, currently using ktime_get() for presentation > time > - get time from shim into TSN and vice versa > - let shim create/manage buffer > > Henrik Austad (8): > TSN: add documentation > TSN: Add the standard formerly known as AVB to the kernel > Adding TSN-driver to Intel I210 controller > Add TSN header for the driver > Add TSN machinery to drive the traffic from a shim over the network > Add TSN event-tracing > AVB ALSA - Add ALSA shim for TSN > MAINTAINERS: add TSN/AVB-entries > > Documentation/TSN/tsn.txt | 147 + > MAINTAINERS | 14 + > drivers/media/Kconfig | 15 + > drivers/media/Makefile| 3 +- > drivers/media/avb/Makefile| 5 + > drivers/media/avb/avb_alsa.c | 742 +++ > drivers/media/avb/tsn_iec61883.h | 124 > drivers/net/ethernet/intel/Kconfig
