From: Takashi Sakamoto <o-takashi@sakamocchi.jp>
To: Clemens Ladisch <clemens@ladisch.de>
Cc: alsa-devel@alsa-project.org, stefanr@s5r6.in-berlin.de,
fenlason@redhat.com
Subject: Re: [RFC][PATCH 00/15 v4] OXFW driver, a succesor to firewire-speakers
Date: Thu, 16 Oct 2014 23:31:06 +0900 [thread overview]
Message-ID: <543FD6AA.5080004@sakamocchi.jp> (raw)
In-Reply-To: <53E9BDC2.3000801@ladisch.de>
Clemens,
Today I got my show-stopper (Griffin FireWave) for OXFW driver and
investigate it with
easy script (see the end of this message).
Currently firewire-speakers driver handles this device but there're
known issues that:
1.the device doesn't generate sounds at some combinations between
channels and rates
2.96.0kHz/2ch seems not supported.
As a result of my investigation:
The device is known to have two modes: 5.1ch surround mode and Dolby Pro
Logic II mode.
At the former mode, stream transfers 6 PCM frames. At the latter mode,
stream stransfers 2 PCM frames. The driver can switch these modes to
execute AV/C Stream Format Information command with Single
subfunction[1]. The purpose of this command is to change internal
formation of a packet. Available formations can be retrieved by AV/C
Stream Format Information command with Single subfunction[1].
$ ./firewave.sh get
Supported stream formats:
response: 000: 0c ff bf c1 00 00 00 00 ff 00 00 90 40 04 02 01
............@...
response: 010: 06 06 ..
response: 000: 0c ff bf c1 00 00 00 00 ff 00 01 90 40 02 02 01
............@...
response: 010: 06 06 ..
response: 000: 0c ff bf c1 00 00 00 00 ff 00 02 90 40 03 02 01
............@...
response: 010: 06 06 ..
response: 000: 0c ff bf c1 00 00 00 00 ff 00 03 90 40 05 02 01
............@...
response: 010: 06 06 ..
response: 000: 0c ff bf c1 00 00 00 00 ff 00 04 90 40 02 02 01
............@...
response: 010: 02 00 ..
response: 000: 0c ff bf c1 00 00 00 00 ff 00 05 90 40 03 02 01
............@...
response: 010: 02 00 ..
response: 000: 0c ff bf c1 00 00 00 00 ff 00 06 90 40 04 02 01
............@...
response: 010: 02 00 ..
response: 000: 0a ff bf c1 00 00 00 00 ff ff 07 ff ............
Current stream format:
response: 000: 0c ff bf c0 00 00 00 00 ff 00 90 40 04 02 01 06
...........@....
response: 010: 06 .
Supported sampling rates in current number of channels:
response: 000: 0c ff 19 00 90 00 ff ff ........
response: 000: 0c ff 19 00 90 01 ff ff ........
response: 000: 0c ff 19 00 90 02 ff ff ........
response: 000: 08 ff 19 00 90 03 ff ff ........
response: 000: 0c ff 19 00 90 04 ff ff ........
response: 000: 08 ff 19 00 90 05 ff ff ........
response: 000: 08 ff 19 00 90 06 ff ff ........
According to this output, the available formations of this device are:
Mode A. 6ch Multi Bit Linear Audio (MBLA) data at 32.0/44.1/48.0/96.0kHz
Mode B. 2ch IEC60958 Compliant data at 32.0/44.1/48.0kHz
For the detail of MBLA and IEC 60958 Compliant data, please refer to
[2]. The mode A is equivalent to 5.1ch surround mode, and mode B is
equivalent to Dolby Pro Logic II mode. FYI, the last commands are AV/C
Plug Signal Format commands[3] and they show the device generally
supports 32.0/44.1/48.0/96.0.
As long as I tested, the driver (firewire-speaker) can playback and the
device successfully generates sound unless the driver attempts to
transfer packets with different number of channels against current
setting. For example, when 2ch/48.0kHz is set, then playbacks at 2ch
32.0/44.1/48.0 are successful.
Or when 6ch/32.0kHz is set, then playbacks at 6ch 32.0/44.1/48.0/96.0
are successful.
But when the driver attempt to transfer packets with different number of
channels, this operation freezes the device. The device desn't react
transactions anymore. For example:
$ ./firewave.sh set 44100 6
response: 000: 09 ff bf c0 00 00 00 00 ff 00 90 40 03 02 01 06
...........@....
response: 010: 06 .
$ aplay -D hw:FireWave,0 -f S32_LE -c 2 -r 44100 /dev/urandom
(the application and the device freeze)
This causes a bad effect to userspace applications, especially
PulseAudio.When connecting sound devices, PulseAudio starts any streams
to detect its channel profiles. For FireWave, PulseAudio starts two
streams: 2ch and 6ch streams. These operations can freeze the device.
For 96.0kHz/2ch, I tried this:
$ ./firewave.sh set 48000 2
response: 000: 09 ff bf c0 00 00 00 00 ff 00 90 40 04 02 01 02
...........@....
response: 010: 00 .
$ aplay -D hw:FireWave -f S32_LE -c 2 -r 96000 /dev/urandom
The device is expected to generate noise but it sounds nothing. Thus I
think the device doesn't support this mode.
I have a plan to include improvements for this issue to my patchset for
OXFW driver. The patchset will be posted till the beginning of next
month, I think.
[1] TA Document 2004008, AV/C Stream Format Information Specification
1.1 (working draft) (April 15, 2005, 1394TA)
[2] IEC 61883-6:2005 Consumer audio/video equipment - Digital interface -
Part 6: Audio and Music Data Transmission Protocol, Edition 2.0
[2] TA Document 2004006, AV/C Digital Interface Command Set General
Specification Version 4.2 (September 1, 2004, 1394TA)
Regards
Takashi Sakamoto
o-takashi@sakamocchi.jp
----- 8< -----
$ cat ./firewave.sh
#!/bin/bash
if [ $# -lt 1 ] || [[ $1 != "get" ]] && [[ $1 != "set" ]]; then
echo "firewave.sh 'get'"
echo "firewave.sh 'set' (32000|44100|48000|96000) (2|6)"
exit
fi
if [[ $1 == get ]]; then
echo "Supported stream formats:"
# AV/C Stream Format Information command with List subfunction
for i in $(seq 0 7) ; do
./firewire-request /dev/fw1 fcp $(printf
"0x01ffbfc100000000ffff%02xff" $i)
done
echo "Current stream format:"
# AV/C Stream Format Information command with Single subfunction
./firewire-request /dev/fw1 fcp 0x01ffbfc000000000ffffffff
echo "Supported sampling rates in current number of channels:"
# AV/C Plug Signal Format command
for i in $(seq 0 6); do
./firewire-request /dev/fw1 fcp $(printf "0x02ff190090%02xffff" $i)
done
exit
fi
if [ ! $# -eq 3 ]; then
echo 'Invalid number of arguments.'
exit
fi
if [ $2 -eq 32000 ] && [ $3 -eq 6 ]; then
rate=2
ch=6
format=6
elif [ $2 -eq 44100 ] && [ $3 -eq 6 ]; then
rate=3
ch=6
format=6
elif [ $2 -eq 48000 ] && [ $3 -eq 6 ]; then
rate=4
ch=6
format=6
elif [ $2 -eq 96000 ] && [ $3 -eq 6 ]; then
rate=5
ch=6
format=6
elif [ $2 -eq 32000 ] && [ $3 -eq 2 ]; then
rate=2
ch=2
format=0
elif [ $2 -eq 44100 ] && [ $3 -eq 2 ]; then
rate=3
ch=2
format=0
elif [ $2 -eq 48000 ] && [ $3 -eq 2 ]; then
rate=4
ch=2
format=0
elif [ $2 -eq 96000 ] && [ $3 -eq 2 ]; then
rate=5
ch=2
format=0
else
echo "Unsupported combination between rate and channel."
exit
fi
# AV/C Stream Format Information command with Single subfunction
./firewire-request /dev/fw1 fcp $(printf
"0x00ffbfc000000000ff009040%02x0201%02x%02x" $rate $ch $format)
next prev parent reply other threads:[~2014-10-16 14:31 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-13 14:27 [RFC][PATCH 00/15 v4] OXFW driver, a succesor to firewire-speakers Takashi Sakamoto
2014-05-13 14:27 ` [PATCH 01/15] speakers: Rename to oxfw and rename some members Takashi Sakamoto
2014-05-13 14:27 ` [PATCH 02/15] oxfw: Move to its own directory Takashi Sakamoto
2014-05-13 14:27 ` [PATCH 03/15] oxfw: Split stream functionality to a new file and add a header file Takashi Sakamoto
2014-05-13 14:27 ` [PATCH 04/15] oxfw: Split PCM functionality to a new file Takashi Sakamoto
2014-05-13 14:27 ` [PATCH 05/15] oxfw: Split control " Takashi Sakamoto
2014-05-13 14:27 ` [PATCH 06/15] oxfw: Change the way to name card Takashi Sakamoto
2014-05-13 14:27 ` [PATCH 07/15] oxfw: Change the way to make PCM rules/constraints Takashi Sakamoto
2014-05-13 14:27 ` [PATCH 08/15] oxfw: Add proc interface for debugging purpose Takashi Sakamoto
2014-05-13 14:27 ` [PATCH 09/15] oxfw: Change the way to start stream Takashi Sakamoto
2014-05-13 14:27 ` [PATCH 10/15] oxfw: Add support for AV/C stream format command to get supported stream formation Takashi Sakamoto
2014-05-13 14:27 ` [PATCH 11/15] oxfw: Add a quirk for Griffin FireWave Takashi Sakamoto
2014-05-13 14:27 ` [PATCH 12/15] oxfw: Add support for Behringer/Mackie devices Takashi Sakamoto
2014-08-10 15:54 ` [alsa-devel] " Clemens Ladisch
2014-08-11 23:48 ` Takashi Sakamoto
2014-08-12 7:33 ` [alsa-devel] " Clemens Ladisch
2014-08-12 23:21 ` Takashi Sakamoto
2014-08-13 6:41 ` Clemens Ladisch
2014-08-13 7:00 ` Takashi Sakamoto
2014-08-13 7:07 ` Clemens Ladisch
2014-08-13 7:57 ` Takashi Sakamoto
2014-05-13 14:27 ` [PATCH 13/15] oxfw: Add support AMDTP in-stream and PCM capture Takashi Sakamoto
2014-05-13 14:27 ` [PATCH 14/15] oxfw: Add support for capture/playback MIDI messages Takashi Sakamoto
2014-05-13 14:27 ` [PATCH 15/15] oxfw: Add hwdep interface Takashi Sakamoto
2014-05-13 17:43 ` [RFC][PATCH 00/15 v4] OXFW driver, a succesor to firewire-speakers Stefan Richter
2014-05-14 14:15 ` Takashi Sakamoto
2014-08-10 15:54 ` Clemens Ladisch
2014-08-11 23:55 ` Takashi Sakamoto
2014-08-12 7:09 ` Clemens Ladisch
2014-08-12 22:45 ` Takashi Sakamoto
2014-08-13 7:06 ` Clemens Ladisch
2014-08-13 22:55 ` Takashi Sakamoto
2014-10-16 14:31 ` Takashi Sakamoto [this message]
2014-10-26 12:00 ` Stefan Richter
2014-10-26 14:15 ` Takashi Sakamoto
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=543FD6AA.5080004@sakamocchi.jp \
--to=o-takashi@sakamocchi.jp \
--cc=alsa-devel@alsa-project.org \
--cc=clemens@ladisch.de \
--cc=fenlason@redhat.com \
--cc=stefanr@s5r6.in-berlin.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