linux1394-user Mailing List for IEEE 1394 for Linux (Page 4)
Brought to you by:
aeb,
bencollins
You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(29) |
Nov
(36) |
Dec
(46) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(60) |
Feb
(82) |
Mar
(46) |
Apr
(50) |
May
(89) |
Jun
(60) |
Jul
(80) |
Aug
(130) |
Sep
(104) |
Oct
(105) |
Nov
(123) |
Dec
(107) |
2002 |
Jan
(142) |
Feb
(105) |
Mar
(63) |
Apr
(117) |
May
(136) |
Jun
(75) |
Jul
(105) |
Aug
(103) |
Sep
(149) |
Oct
(149) |
Nov
(98) |
Dec
(144) |
2003 |
Jan
(161) |
Feb
(100) |
Mar
(118) |
Apr
(126) |
May
(157) |
Jun
(173) |
Jul
(156) |
Aug
(89) |
Sep
(83) |
Oct
(106) |
Nov
(84) |
Dec
(69) |
2004 |
Jan
(119) |
Feb
(233) |
Mar
(232) |
Apr
(104) |
May
(113) |
Jun
(132) |
Jul
(87) |
Aug
(129) |
Sep
(186) |
Oct
(88) |
Nov
(148) |
Dec
(180) |
2005 |
Jan
(223) |
Feb
(176) |
Mar
(148) |
Apr
(193) |
May
(188) |
Jun
(236) |
Jul
(144) |
Aug
(89) |
Sep
(44) |
Oct
(86) |
Nov
(114) |
Dec
(89) |
2006 |
Jan
(94) |
Feb
(97) |
Mar
(57) |
Apr
(117) |
May
(46) |
Jun
(63) |
Jul
(51) |
Aug
(72) |
Sep
(50) |
Oct
(142) |
Nov
(70) |
Dec
(52) |
2007 |
Jan
(60) |
Feb
(67) |
Mar
(80) |
Apr
(81) |
May
(78) |
Jun
(52) |
Jul
(64) |
Aug
(55) |
Sep
(40) |
Oct
(87) |
Nov
(70) |
Dec
(44) |
2008 |
Jan
(80) |
Feb
(12) |
Mar
(82) |
Apr
(64) |
May
(33) |
Jun
(53) |
Jul
(41) |
Aug
(26) |
Sep
(35) |
Oct
(21) |
Nov
(30) |
Dec
(42) |
2009 |
Jan
(17) |
Feb
(32) |
Mar
(10) |
Apr
(19) |
May
(19) |
Jun
(28) |
Jul
(41) |
Aug
(14) |
Sep
(5) |
Oct
(46) |
Nov
(23) |
Dec
(20) |
2010 |
Jan
(46) |
Feb
(13) |
Mar
(9) |
Apr
(2) |
May
(19) |
Jun
(28) |
Jul
(37) |
Aug
(23) |
Sep
(5) |
Oct
(32) |
Nov
(19) |
Dec
(18) |
2011 |
Jan
(23) |
Feb
(9) |
Mar
(19) |
Apr
(38) |
May
(83) |
Jun
(30) |
Jul
(46) |
Aug
(32) |
Sep
(6) |
Oct
(3) |
Nov
(25) |
Dec
(31) |
2012 |
Jan
(21) |
Feb
(12) |
Mar
(19) |
Apr
(7) |
May
(27) |
Jun
(7) |
Jul
(2) |
Aug
(15) |
Sep
(8) |
Oct
(11) |
Nov
|
Dec
(3) |
2013 |
Jan
|
Feb
|
Mar
(2) |
Apr
(1) |
May
(1) |
Jun
(14) |
Jul
(1) |
Aug
(3) |
Sep
(4) |
Oct
(5) |
Nov
|
Dec
|
2014 |
Jan
(14) |
Feb
(2) |
Mar
(1) |
Apr
(3) |
May
(2) |
Jun
(7) |
Jul
(2) |
Aug
(1) |
Sep
|
Oct
(14) |
Nov
(5) |
Dec
(18) |
2015 |
Jan
(3) |
Feb
(1) |
Mar
(3) |
Apr
(5) |
May
|
Jun
(3) |
Jul
(4) |
Aug
|
Sep
(2) |
Oct
(11) |
Nov
(2) |
Dec
|
2016 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(5) |
Jul
(1) |
Aug
(1) |
Sep
(2) |
Oct
(2) |
Nov
|
Dec
|
2017 |
Jan
|
Feb
(5) |
Mar
(7) |
Apr
|
May
(4) |
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
|
2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
(1) |
Mar
(2) |
Apr
|
May
(1) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(6) |
2021 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2023 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Clemens L. <cl...@la...> - 2014-12-12 19:46:48
|
Daniel Robbins wrote: > On Fri, Dec 12, 2014 at 1:15 AM, Clemens Ladisch <cl...@la...> wrote: >> Does "aplay -D hw:1 -f S32_LE -c 2 -r 176400 -t raw /dev/zero" work? > > Depends what you mean by "work". Here is the output: > > node ~ # aplay -D hw:1 -f S32_LE -c 2 -r 176400 -t raw /dev/zero > Playing raw data '/dev/zero' : Signed 32 bit Little Endian, Rate 176400 Hz, Stereo > aplay: set_params:1239: Channels count non available And you DoP stuff uses two channels? That would be the problem then. Try using plughw:1 instead. Regards, Clemens |
From: Daniel R. <dro...@fu...> - 2014-12-12 19:20:20
|
On Fri, Dec 12, 2014 at 1:15 AM, Clemens Ladisch <cl...@la...> wrote: > Does "aplay -D hw:1 -f S32_LE -c 2 -r 176400 -t raw /dev/zero" work? Depends what you mean by "work". Here is the output: node ~ # aplay -D hw:1 -f S32_LE -c 2 -r 176400 -t raw /dev/zero Playing raw data '/dev/zero' : Signed 32 bit Little Endian, Rate 176400 Hz, Stereo aplay: set_params:1239: Channels count non available node ~ # Regards, Daniel |
From: Clemens L. <cl...@la...> - 2014-12-12 08:15:50
|
Daniel Robbins wrote: > It appears to be having problems with S32_LE: > > Dec 09 21:03 : output: closed plugin=alsa name="ALSA-firewire" > Dec 09 21:03 : alsa_output: opened hw:1,0 type=HW > Dec 09 21:03 : alsa_output: format=S32_LE (Signed 32 bit Little Endian) At this point, S32_LE is confirmed to be supported. > Dec 09 21:03 : alsa_output: buffer: size=896..1048576 time=5079..5944309 > Dec 09 21:03 : alsa_output: period: size=896..1048576 time=5079..5944309 > Dec 09 21:03 : alsa_output: default period_time = buffer_time/4 = 499954/4 = 124988 > Dec 09 21:03 : alsa_output: buffer_size=88192 period_size=22048 At this point, the hardware has been configured successfully. > Dec 09 21:03 : alsa_output: Failed to open "ALSA-firewire" [alsa]: Failed to configure DSD-over-PCM on ALSA device "hw:1,0" And now it aborts. The only explanation is that channels or sample_rate changed. Does "aplay -D hw:1 -f S32_LE -c 2 -r 176400 -t raw /dev/zero" work? Regards, Clemens |
From: Daniel R. <dro...@fu...> - 2014-12-09 23:56:31
|
On Tue, Dec 9, 2014 at 4:45 PM, Daniel Robbins <dro...@fu...> wrote: > > It appears to be having problems with S32_LE: > > Dec 09 21:03 : output: closed plugin=alsa name="ALSA-firewire" > Dec 09 21:03 : alsa_output: opened hw:1,0 type=HW I purchased a TI chipset PCI-E card to do more testing, and just reproduced the exact same test on the new machine. The TI card experiences the exact same issue. It can't do S32_LE. So it doesn't appear to be a VIA vs. TI issue. The old system that worked had a TI chip on a PCI (not PCI-E) card, and had a very similar setup. But apparently, there are enough differences in the kernel/other places for the TI PCI card to work, but the TI/VIA PCI-E cards to not work in the new system. Regards, Daniel |
From: Daniel R. <dro...@fu...> - 2014-12-09 23:45:34
|
On Mon, Dec 8, 2014 at 11:30 AM, Clemens Ladisch <cl...@la...> wrote: > This message means that the device does not support the S24 or S32 > sample formats. However, FireWire devices definitively support S32. > > Please set log_level to verbose and check what mpd's alsa driver > says then. It appears to be having problems with S32_LE: Dec 09 21:03 : output: closed plugin=alsa name="ALSA-firewire" Dec 09 21:03 : alsa_output: opened hw:1,0 type=HW Dec 09 21:03 : alsa_output: format=S32_LE (Signed 32 bit Little Endian) Dec 09 21:03 : alsa_output: buffer: size=896..1048576 time=5079..5944309 Dec 09 21:03 : alsa_output: period: size=896..1048576 time=5079..5944309 Dec 09 21:03 : alsa_output: default period_time = buffer_time/4 = 499954/4 = 124988 Dec 09 21:03 : alsa_output: buffer_size=88192 period_size=22048 Dec 09 21:03 : alsa_output: Failed to open "ALSA-firewire" [alsa]: Failed to configure DSD-over-PCM on ALSA device "hw:1,0" Dec 09 21:03 : output: Failed to open audio output Regards, Daniel |
From: Clemens L. <cl...@la...> - 2014-12-08 18:30:39
|
Daniel Robbins wrote: > it can do high bitrate PCM just fine, but it fails on DOP: > > [alsa]: Failed to configure DSD-over-PCM on ALSA device "hw:1,0" This message means that the device does not support the S24 or S32 sample formats. However, FireWire devices definitively support S32. Please set log_level to verbose and check what mpd's alsa driver says then. Regards, Clemens |
From: Daniel R. <dro...@fu...> - 2014-12-08 16:42:12
|
On Mon, Dec 8, 2014 at 6:03 AM, Clemens Ladisch <cl...@la...> wrote: > Does mpd actually use the "hw" device, and not "dmix" (or "default"), > which would force everything to 48 kHz? I made sure it is using the "hw" device, and now it can do high bitrate PCM just fine, but it fails on DOP: Dec 08 16:35 : alsa_output: Failed to open "ALSA-firewire" [alsa]: Failed to configure DSD-over-PCM on ALSA device "hw:1,0" Regards, Daniel |
From: Clemens L. <cl...@la...> - 2014-12-08 13:03:37
|
Daniel Robbins wrote: > For PCM, it seems that mpd (music program) is able to "see" that > >48KHz is not supported, and resamples >48KHz PCM audio to 48KHz (for > 96KHz, 192, etc.). Does mpd actually use the "hw" device, and not "dmix" (or "default"), which would force everything to 48 kHz? Regards, Clemens |
From: Daniel R. <dro...@fu...> - 2014-12-03 19:07:46
|
Any more information I can provide on this? I now have two firewire cards with this VIA chip and they are unable to output >48KHz. -Daniel On Fri, Nov 21, 2014 at 9:19 AM, Daniel Robbins <dro...@fu...> wrote: > For PCM, it seems that mpd (music program) is able to "see" that >48KHz is > not supported, and resamples >48KHz PCM audio to 48KHz (for 96KHz, 192, > etc.). > > For DOP, the DAC stays locked at the bitrate it was on previously (when > switching from a PCM track, so either 44.1 or 48KHz). There is no audible > output, but level meters show very low-level audio output (below -60db). I > am able to pause this to zero the level meters. > > This seems similar to the behavior I saw when we had non-functioning > dual-wire on my older system, except higher bitrate PCM did work just fine > whereas in this case, the DAC is not put into anything higher than 48KHz. > > Regards, > > Daniel > > On Fri, Nov 21, 2014 at 9:13 AM, Clemens Ladisch <cl...@la...> > wrote: > >> Daniel Robbins wrote: >> > I am unable to get a PCM bitrate greater than 48KHz >> >> What happens? >> >> >> Regards, >> Clemens >> > > |
From: Clemens L. <cl...@la...> - 2014-12-02 18:35:00
|
Erwann Thoraval wrote: > firewire_ohci: DMA context IR0 has stopped, error code: evt_descriptor_read This message means that the controller tried to read something from main memory, but failed. Complete memory read failures are not really possible, so the most likely cause is that the response from the memory controller was not received fast enough. > After this error, the computer usually freezes for about 5 minutes and > then comes back to life. Strange. Any other messages in the system log when this happens? > Finally, on more information i've discovered this morning: these issues > happens when the laptop is on battery. Until now, i don't face any issue > when plugged to AC. It might be possible that the CPU goes into a deeper sleep mode when on battery, and takes longer to wake up and serve DMA requests. > I tried to turn on debugging messages: > ... no crashes anymore! (except filling debug files, it works like a > charm for hours) <- that is what i wrote to dvswitch-devel ML, but it > eventually crashes, much more lately though. If the CPU has more work, it goes to sleep less often. Could you try to disable CPU frequency switching? Regards, Clemens |
From: Carl K. <ca...@pe...> - 2014-12-02 14:53:27
|
ignore dvswitch for now, just use dvgrab until this is worked out. For the list: dvswitch wraps dvgrab. > these issues > happens when the laptop is on battery. Until now, i don't face any issue > when plugged to AC. How good is the laptop's battery? Like will it run the laptop for more than 20 minutes? The only thing I can really think of that should matter is power management, like the CPU slows down after a few minutes. Can you disable anything like that? Or change everything to go into power save mode sooner, like 30 seconds and see if the problem starts sooner. What is powering the DV camera? (camera battery or power adaptor) Can you change the power source of the DV cam and try dvgrab again (ignore dvswitch for now) On Tue, Dec 2, 2014 at 4:43 AM, Erwann Thoraval < erw...@su...> wrote: > Hello list, > > I am facing a problem when using dvswitch and a firewire cam. > > After having started dvswitch and dvsource, i wait for 2 or 3 minutes > (sometimes less), and dvsource looses the firewire stream, with this > message in log files: > > firewire_ohci 0000:05:00.0: DMA context IR0 has stopped, error code: > evt_descriptor_read > > I tried to turn on debugging messages: > # rmmod firewire_ohci > # modprobe firewire_ohci debug=7 > # echo 8 > /proc/sysrq-trigger > > ... no crashes anymore! (except filling debug files, it works like a > charm for hours) <- that is what i wrote to dvswitch-devel ML, but it > eventually crashes, much more lately though. > > After this error, the computer usually freezes for about 5 minutes and > then comes back to life. > > Upon advices of Carl@dvswitch-devel, i ran dvgrab -debug video instead > of using the whole dvswitch suite. The problem still happens, and i > don't have more information from dvgrab's debug output. > > Finally, on more information i've discovered this morning: these issues > happens when the laptop is on battery. Until now, i don't face any issue > when plugged to AC. > > > My setup is as follow: > Macbook pro with debian stable (wheezy + backports) > Sony HVR-A1E firewire cam > > linux-image-3.16-0.bpo.3-amd64 (it used to be 3.2.0, i tried to upgrade > to get rid of these crashes) > dvswitch, dvsink, dvsource 0.8.3.6-1+b2 > dvgrab 3.5-2 > 05:00.0 FireWire (IEEE 1394): LSI Corporation FW643 [TrueFire] PCIe > 1394b Controller (rev 07) > > > Is there something wrong with my setup? > Any idea about how to find the issue? > > Any help would be greatly appreciated :) > > Cheers, > Erwann > > > ------------------------------------------------------------------------------ > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & more > Get technology previously reserved for billion-dollar corporations, FREE > > http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk > _______________________________________________ > mailing list Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux1394-user > -- Carl K Aaron Swartz believed that you literally ought to be asking yourself all the time: "What is most important thing I could be working on in the world right now, and if you're not working on it, why aren't you?" |
From: Erwann T. <erw...@su...> - 2014-12-02 11:01:40
|
Hello list, I am facing a problem when using dvswitch and a firewire cam. After having started dvswitch and dvsource, i wait for 2 or 3 minutes (sometimes less), and dvsource looses the firewire stream, with this message in log files: firewire_ohci 0000:05:00.0: DMA context IR0 has stopped, error code: evt_descriptor_read I tried to turn on debugging messages: # rmmod firewire_ohci # modprobe firewire_ohci debug=7 # echo 8 > /proc/sysrq-trigger ... no crashes anymore! (except filling debug files, it works like a charm for hours) <- that is what i wrote to dvswitch-devel ML, but it eventually crashes, much more lately though. After this error, the computer usually freezes for about 5 minutes and then comes back to life. Upon advices of Carl@dvswitch-devel, i ran dvgrab -debug video instead of using the whole dvswitch suite. The problem still happens, and i don't have more information from dvgrab's debug output. Finally, on more information i've discovered this morning: these issues happens when the laptop is on battery. Until now, i don't face any issue when plugged to AC. My setup is as follow: Macbook pro with debian stable (wheezy + backports) Sony HVR-A1E firewire cam linux-image-3.16-0.bpo.3-amd64 (it used to be 3.2.0, i tried to upgrade to get rid of these crashes) dvswitch, dvsink, dvsource 0.8.3.6-1+b2 dvgrab 3.5-2 05:00.0 FireWire (IEEE 1394): LSI Corporation FW643 [TrueFire] PCIe 1394b Controller (rev 07) Is there something wrong with my setup? Any idea about how to find the issue? Any help would be greatly appreciated :) Cheers, Erwann |
From: Daniel R. <dro...@fu...> - 2014-11-21 16:19:15
|
For PCM, it seems that mpd (music program) is able to "see" that >48KHz is not supported, and resamples >48KHz PCM audio to 48KHz (for 96KHz, 192, etc.). For DOP, the DAC stays locked at the bitrate it was on previously (when switching from a PCM track, so either 44.1 or 48KHz). There is no audible output, but level meters show very low-level audio output (below -60db). I am able to pause this to zero the level meters. This seems similar to the behavior I saw when we had non-functioning dual-wire on my older system, except higher bitrate PCM did work just fine whereas in this case, the DAC is not put into anything higher than 48KHz. Regards, Daniel On Fri, Nov 21, 2014 at 9:13 AM, Clemens Ladisch <cl...@la...> wrote: > Daniel Robbins wrote: > > I am unable to get a PCM bitrate greater than 48KHz > > What happens? > > > Regards, > Clemens > |
From: Clemens L. <cl...@la...> - 2014-11-21 16:13:46
|
Daniel Robbins wrote: > I am unable to get a PCM bitrate greater than 48KHz What happens? Regards, Clemens |
From: Daniel R. <dro...@fu...> - 2014-11-21 15:47:54
|
Hi Clemens, all: I recently set up a new system with a PCI Express firewire card. I am unable to get a PCM bitrate greater than 48KHz, and DSD/DOP does not function at all. <=48KHz PCM functions as expected. Kernel is 'vanilla' 3.17.3. I am using the following card: 01:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6315 Series Firewire Controller (prog-if 10 [OHCI]) Subsystem: VIA Technologies, Inc. VT6315 Series Firewire Controller Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at f0500000 (64-bit, non-prefetchable) [size=2K] I/O ports at e000 [size=256] Capabilities: [50] Power Management version 3 Capabilities: [80] MSI: Enable- Count=1/1 Maskable+ 64bit+ Capabilities: [98] Express Endpoint, MSI 00 Capabilities: [100] Advanced Error Reporting Capabilities: [130] Device Serial Number 00-90-21-ff-ff-00-00-0e Kernel driver in use: firewire_ohci Kernel modules: firewire_ohci This card is branded by NewEgg as Syba but the packaging says "IOCrest". This is the actual card: http://www.newegg.com/Product/Product.aspx?Item=N82E16815124138&cm_re=firewire_pci_express_card-_-15-124-138-_-Product Regards, Daniel |
From: Stefan R. <st...@s5...> - 2014-10-23 07:54:20
|
On Oct 22 Daniel Robbins wrote: > I consider audio playback a more general function of the kernel that > is used much more often and something that should "just work". For > finding the best solution for Linux users, it is often a good idea to > consider potential use cases. So let's look at both: > > If you are doing audio recording, you are performing additional setup > (including recording app, drivers, microphones) and blacklisting a > module as part of this already more involved process is not > unreasonable. You are not likely to be inconvenienced significantly by > performing this step as it is a small part of a larger and more > ambitious goal. It requires a slight change in user behavior but is > not what I would consider a regression. (We did in fact already inconvenience many FFADO users when we replaced the ieee1394 driver family by the firewire driver family, and discovered several driver bugs/ libraw1394 bugs/ previously hidden hardware quirks that had to be resolved. And we will somewhat inconvenience FFADO users again, but hopefully create less trouble than before, while Sakamoto-san's bidirectional FireWire ALSA drivers are being merged into the mainline kernel.) > Now consider the person using dice just for playback, maybe just to > listen to music through their stereo with their fancy new DAC, and > hoping to use Linux, but with access to maybe Windows or MacOS > systems, so they are not willing to invest a ton of time in making > this work on Linux (I am more the exception than the rule.) If they > are using a pre-built kernel, they are currently stuck with no audio. > Not a good situation. Specifying a kernel boot option for audio > playback to work requires an additional step that most users will not > perform since they will not be aware that it is required. They will > just not have audio, and will not look at the kernel sources to see > why, and think it is broken. So they will abandon Linux for streaming > music to their DAC. Also not a good situation. > > So, I think it's clear what option provides the optimal user > experience that is most likely to allow people to benefit from Linux > support for this hardware. I consider the current behavior to be a > regression in _behavior_ for a module, which is almost always: "if I > am 'modprobe'd, and I find a device that I support, then I will > function as expected with no additional kernel-related configuration > options.' This is the norm that users expect. So when there is > deviation from this norm, that is something that is more of a true > regression, in my opinon. You are raising valid points; on the other hand consider this: - kernels 3.12 and older: - support bidirectional DICE devices via FFADO out of the box (the limitation to bidi is FFADO's, not the kernel's) - do not support support DICE via ALSA - kernels 3.13...3.18: - still support bidi DICE via FFADO out of the box - newly support unidi DICE via ALSA out of the box - still do not support bidi DICE via ALSA So there is currently a other-OS-to-Linux regression, but no Linux-to-Linux regression. > Thanks to everyone who has helped to provide such high-quality > firewire sound drivers for Linux. > > -Daniel -- Stefan Richter -=====-====- =-=- =-=== http://arcgraph.de/sr/ |
From: Daniel R. <dro...@fu...> - 2014-10-22 22:34:29
|
I consider audio playback a more general function of the kernel that is used much more often and something that should "just work". For finding the best solution for Linux users, it is often a good idea to consider potential use cases. So let's look at both: If you are doing audio recording, you are performing additional setup (including recording app, drivers, microphones) and blacklisting a module as part of this already more involved process is not unreasonable. You are not likely to be inconvenienced significantly by performing this step as it is a small part of a larger and more ambitious goal. It requires a slight change in user behavior but is not what I would consider a regression. Now consider the person using dice just for playback, maybe just to listen to music through their stereo with their fancy new DAC, and hoping to use Linux, but with access to maybe Windows or MacOS systems, so they are not willing to invest a ton of time in making this work on Linux (I am more the exception than the rule.) If they are using a pre-built kernel, they are currently stuck with no audio. Not a good situation. Specifying a kernel boot option for audio playback to work requires an additional step that most users will not perform since they will not be aware that it is required. They will just not have audio, and will not look at the kernel sources to see why, and think it is broken. So they will abandon Linux for streaming music to their DAC. Also not a good situation. So, I think it's clear what option provides the optimal user experience that is most likely to allow people to benefit from Linux support for this hardware. I consider the current behavior to be a regression in _behavior_ for a module, which is almost always: "if I am 'modprobe'd, and I find a device that I support, then I will function as expected with no additional kernel-related configuration options.' This is the norm that users expect. So when there is deviation from this norm, that is something that is more of a true regression, in my opinon. Thanks to everyone who has helped to provide such high-quality firewire sound drivers for Linux. -Daniel On Wed, Oct 22, 2014 at 2:32 PM, Stefan Richter <st...@s5...> wrote: > On Oct 22 Daniel Robbins wrote: >> I now have firewire audio working with 3.17.1. But I still have to >> hack the kernel sources to get this to work... the remaining problem >> with dice.c is the fact that it disables itself if it sees that the >> device has record capabilities, assuming you will use FFADO. > > With a little bit more patching than that, you could even modify the > driver to support capture: > https://github.com/takaswie/snd-firewire-improve . > (I haven't tested this myself yet.) > >> Well, guess what? I would just like my firewire audio to just work >> in-kernel without modifying source code. I request that you remove this >> artificial limitation of the driver. > > I too would be in favor of this limitation being lifted (unless > Sakamoto-san's work goes into the mainline sooner, of course), but with a > qualification; see below. > >> My Mytek DSD DAC is used for playback only, so just because a device >> advertises record capability doesn't actually mean it is a record >> device in practice. The module should load and function, and if the >> user doesn't want to use it, they can blacklist it. My opinion of >> course, but what good reason is there to have snd-dice *not* function >> without hacking source code when it could by default? > > For users of DICE devices for recording, it would currently be a regression > if the kernel prevented FFADO from accessing the device. There would be > two alternative solutions: Either recording users would need to add a > module blacklist rule on their systems. Or the playback-only driver > would be extended by a module parameter that tells it to bind to bidi > devices too, and that parameter would be off by default. With the > second approach, users who only require playback through their bidi device > would have to add a module parameter config on their systems, while users > who want to record do not need to reconfigure anything. > -- > Stefan Richter > -=====-====- =-=- =-==- > http://arcgraph.de/sr/ |
From: Stefan R. <st...@s5...> - 2014-10-22 20:33:12
|
On Oct 22 Daniel Robbins wrote: > I now have firewire audio working with 3.17.1. But I still have to > hack the kernel sources to get this to work... the remaining problem > with dice.c is the fact that it disables itself if it sees that the > device has record capabilities, assuming you will use FFADO. With a little bit more patching than that, you could even modify the driver to support capture: https://github.com/takaswie/snd-firewire-improve . (I haven't tested this myself yet.) > Well, guess what? I would just like my firewire audio to just work > in-kernel without modifying source code. I request that you remove this > artificial limitation of the driver. I too would be in favor of this limitation being lifted (unless Sakamoto-san's work goes into the mainline sooner, of course), but with a qualification; see below. > My Mytek DSD DAC is used for playback only, so just because a device > advertises record capability doesn't actually mean it is a record > device in practice. The module should load and function, and if the > user doesn't want to use it, they can blacklist it. My opinion of > course, but what good reason is there to have snd-dice *not* function > without hacking source code when it could by default? For users of DICE devices for recording, it would currently be a regression if the kernel prevented FFADO from accessing the device. There would be two alternative solutions: Either recording users would need to add a module blacklist rule on their systems. Or the playback-only driver would be extended by a module parameter that tells it to bind to bidi devices too, and that parameter would be off by default. With the second approach, users who only require playback through their bidi device would have to add a module parameter config on their systems, while users who want to record do not need to reconfigure anything. -- Stefan Richter -=====-====- =-=- =-==- http://arcgraph.de/sr/ |
From: Daniel R. <dro...@fu...> - 2014-10-22 18:25:54
|
All, Gerry resolved this issue. It was indeed a regression in the interrupt code affecting 3.17+. I happen to have a SuperMicro motherboard that has a weird interrupt setup. Gerry, thanks for your help! :) I am attaching the fix below for reference. I now have firewire audio working with 3.17.1. But I still have to hack the kernel sources to get this to work... the remaining problem with dice.c is the fact that it disables itself if it sees that the device has record capabilities, assuming you will use FFADO. Well, guess what? I would just like my firewire audio to just work in-kernel without modifying source code. I request that you remove this artificial limitation of the driver. My Mytek DSD DAC is used for playback only, so just because a device advertises record capability doesn't actually mean it is a record device in practice. The module should load and function, and if the user doesn't want to use it, they can blacklist it. My opinion of course, but what good reason is there to have snd-dice *not* function without hacking source code when it could by default? Regards, Daniel Gerry's IRQ fix patch for my SuperMicro X8SIL motherboard below: diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c index b436fc735aa4..1cf3354845cf 100644 --- a/arch/x86/kernel/acpi/boot.c +++ b/arch/x86/kernel/acpi/boot.c @@ -396,8 +396,10 @@ static int mp_register_gsi(struct device *dev, u32 gsi, int trigger, return gsi; /* Don't set up the ACPI SCI because it's already set up */ - if (acpi_gbl_FADT.sci_interrupt == gsi) - return gsi; + if (acpi_gbl_FADT.sci_interrupt == gsi) { + pr_warn("irqdomain: shared GSI between SCI and PCI\n"); + return mp_map_gsi_to_irq(gsi, 0); + } trigger = trigger == ACPI_EDGE_SENSITIVE ? 0 : 1; polarity = polarity == ACPI_ACTIVE_HIGH ? 0 : 1; @@ -508,7 +510,7 @@ acpi_parse_int_src_ovr(struct acpi_subtable_header * On Mon, Oct 20, 2014 at 9:56 AM, Jiang Liu <jia...@li...> wrote: > Hi Daniel, > Thanks for bisecting and seems the regression is caused > by the commit. But I can't find the full dmesg file posted by you > through googling:(. So could you please help to send the full dmesg > text with the failure kernel? Another dmesg with the working kernel > (v3.16) is preferred too. > Please also send me the output of "acpidump > acpi.bin". > Regards! > Gerry > > On 2014/10/20 5:59, Daniel Robbins wrote: >> I have identified the bad commit: >> >> plex linux-git # git bisect good >> 84245af7297ced9e8fe837dc0fc4782438771bd2 is the first bad commit >> commit 84245af7297ced9e8fe837dc0fc4782438771bd2 >> Author: Jiang Liu <jia...@li...> >> Date: Tue Jun 10 14:14:47 2014 +0800 >> >> x86, irq, ACPI: Change __acpi_register_gsi to return IRQ number >> instead of GSI >> >> Currently __acpi_register_gsi is defined to return GSI number and >> may be set to acpi_register_gsi_pic(), acpi_register_gsi_ioapic(), >> acpi_register_gsi_xen_hvm() and acpi_register_gsi_xen(). >> >> Among which, acpi_register_gsi_ioapic() returns GSI number, but >> acpi_register_gsi_xen_hvm() and acpi_register_gsi_xen() actually >> returns IRQ number instead of GSI. And for acpi_register_gsi_pic(), >> GSI number equals to IRQ number. >> >> So change acpi_register_gsi_ioapic() to return IRQ number, it also >> simplifies the code. >> >> Signed-off-by: Jiang Liu <jia...@li...> >> Cc: Konrad Rzeszutek Wilk <kon...@or...> >> Cc: Tony Luck <ton...@in...> >> Cc: Joerg Roedel <jo...@8b...> >> Cc: Paul Gortmaker <pau...@wi...> >> Cc: Greg Kroah-Hartman <gr...@li...> >> Cc: Benjamin Herrenschmidt <be...@ke...> >> Cc: Grant Likely <gra...@li...> >> Cc: Rafael J. Wysocki <rj...@rj...> >> Cc: Bjorn Helgaas <bhe...@go...> >> Cc: Randy Dunlap <rd...@in...> >> Cc: Yinghai Lu <yi...@ke...> >> Cc: Len Brown <len...@in...> >> Cc: Pavel Machek <pa...@uc...> >> Link: http://lkml.kernel.org/r/140...@li... >> Signed-off-by: Thomas Gleixner <tg...@li...> >> >> :040000 040000 e2ffe2a09062cc3fd40f2367a3f5e47fe3852277 >> 9b690563070c3d0de56a9c950e32cb2def10d08f M arch >> >> On Sun, Oct 19, 2014 at 1:40 PM, Daniel Robbins <dro...@fu...> wrote: >>> And I will start a bisect between 3.16.0 and 3.17.0 and see what is causing >>> this.... >>> >>> -Daniel >>> >>> On Sun, Oct 19, 2014 at 1:16 PM, Daniel Robbins <dro...@fu...> wrote: >>>> >>>> This board only has one PCI slot, and I believe it is using the latest >>>> BIOS. >>>> >>>> I am attaching dmesg from 3.16.0, where the firewire card is handled just >>>> fine (using it to listen to music right now :) I am curious why it works >>>> fine with 3.16.0 and not with 3.17.0+. >>>> >>>> -Daniel >>>> >>>> On Sun, Oct 19, 2014 at 1:10 PM, Clemens Ladisch <cl...@la...> >>>> wrote: >>>>> >>>>> Daniel Robbins wrote: >>>>>> [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 20 low >>>>>> level) >>>>>> [ 2.699224] firewire_ohci 0000:06:00.0: failed to allocate interrupt >>>>>> 20 >>>>> >>>>> Interrupt 20 is actually interrupt 9, which is already used for ACPI >>>>> events. >>>>> (At least this is what the kernel thinks what the BIOS tells it.) >>>>> >>>>> In theory, the controller's "20" is bus_irq, which should not conflict. >>>>> Could you bisect the kernel? >>>>> >>>>> Is this a controller card which you could plug into a different slot? >>>>> Or could you update the motherboard BIOS? >>>>> >>>>> >>>>> Regards, >>>>> Clemens >>>> >>>> >>> |
From: Jiang L. <jia...@li...> - 2014-10-20 15:57:48
|
Hi Daniel, Thanks for bisecting and seems the regression is caused by the commit. But I can't find the full dmesg file posted by you through googling:(. So could you please help to send the full dmesg text with the failure kernel? Another dmesg with the working kernel (v3.16) is preferred too. Please also send me the output of "acpidump > acpi.bin". Regards! Gerry On 2014/10/20 5:59, Daniel Robbins wrote: > I have identified the bad commit: > > plex linux-git # git bisect good > 84245af7297ced9e8fe837dc0fc4782438771bd2 is the first bad commit > commit 84245af7297ced9e8fe837dc0fc4782438771bd2 > Author: Jiang Liu <jia...@li...> > Date: Tue Jun 10 14:14:47 2014 +0800 > > x86, irq, ACPI: Change __acpi_register_gsi to return IRQ number > instead of GSI > > Currently __acpi_register_gsi is defined to return GSI number and > may be set to acpi_register_gsi_pic(), acpi_register_gsi_ioapic(), > acpi_register_gsi_xen_hvm() and acpi_register_gsi_xen(). > > Among which, acpi_register_gsi_ioapic() returns GSI number, but > acpi_register_gsi_xen_hvm() and acpi_register_gsi_xen() actually > returns IRQ number instead of GSI. And for acpi_register_gsi_pic(), > GSI number equals to IRQ number. > > So change acpi_register_gsi_ioapic() to return IRQ number, it also > simplifies the code. > > Signed-off-by: Jiang Liu <jia...@li...> > Cc: Konrad Rzeszutek Wilk <kon...@or...> > Cc: Tony Luck <ton...@in...> > Cc: Joerg Roedel <jo...@8b...> > Cc: Paul Gortmaker <pau...@wi...> > Cc: Greg Kroah-Hartman <gr...@li...> > Cc: Benjamin Herrenschmidt <be...@ke...> > Cc: Grant Likely <gra...@li...> > Cc: Rafael J. Wysocki <rj...@rj...> > Cc: Bjorn Helgaas <bhe...@go...> > Cc: Randy Dunlap <rd...@in...> > Cc: Yinghai Lu <yi...@ke...> > Cc: Len Brown <len...@in...> > Cc: Pavel Machek <pa...@uc...> > Link: http://lkml.kernel.org/r/140...@li... > Signed-off-by: Thomas Gleixner <tg...@li...> > > :040000 040000 e2ffe2a09062cc3fd40f2367a3f5e47fe3852277 > 9b690563070c3d0de56a9c950e32cb2def10d08f M arch > > On Sun, Oct 19, 2014 at 1:40 PM, Daniel Robbins <dro...@fu...> wrote: >> And I will start a bisect between 3.16.0 and 3.17.0 and see what is causing >> this.... >> >> -Daniel >> >> On Sun, Oct 19, 2014 at 1:16 PM, Daniel Robbins <dro...@fu...> wrote: >>> >>> This board only has one PCI slot, and I believe it is using the latest >>> BIOS. >>> >>> I am attaching dmesg from 3.16.0, where the firewire card is handled just >>> fine (using it to listen to music right now :) I am curious why it works >>> fine with 3.16.0 and not with 3.17.0+. >>> >>> -Daniel >>> >>> On Sun, Oct 19, 2014 at 1:10 PM, Clemens Ladisch <cl...@la...> >>> wrote: >>>> >>>> Daniel Robbins wrote: >>>>> [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 20 low >>>>> level) >>>>> [ 2.699224] firewire_ohci 0000:06:00.0: failed to allocate interrupt >>>>> 20 >>>> >>>> Interrupt 20 is actually interrupt 9, which is already used for ACPI >>>> events. >>>> (At least this is what the kernel thinks what the BIOS tells it.) >>>> >>>> In theory, the controller's "20" is bus_irq, which should not conflict. >>>> Could you bisect the kernel? >>>> >>>> Is this a controller card which you could plug into a different slot? >>>> Or could you update the motherboard BIOS? >>>> >>>> >>>> Regards, >>>> Clemens >>> >>> >> |
From: Daniel R. <dro...@fu...> - 2014-10-19 21:59:57
|
I have identified the bad commit: plex linux-git # git bisect good 84245af7297ced9e8fe837dc0fc4782438771bd2 is the first bad commit commit 84245af7297ced9e8fe837dc0fc4782438771bd2 Author: Jiang Liu <jia...@li...> Date: Tue Jun 10 14:14:47 2014 +0800 x86, irq, ACPI: Change __acpi_register_gsi to return IRQ number instead of GSI Currently __acpi_register_gsi is defined to return GSI number and may be set to acpi_register_gsi_pic(), acpi_register_gsi_ioapic(), acpi_register_gsi_xen_hvm() and acpi_register_gsi_xen(). Among which, acpi_register_gsi_ioapic() returns GSI number, but acpi_register_gsi_xen_hvm() and acpi_register_gsi_xen() actually returns IRQ number instead of GSI. And for acpi_register_gsi_pic(), GSI number equals to IRQ number. So change acpi_register_gsi_ioapic() to return IRQ number, it also simplifies the code. Signed-off-by: Jiang Liu <jia...@li...> Cc: Konrad Rzeszutek Wilk <kon...@or...> Cc: Tony Luck <ton...@in...> Cc: Joerg Roedel <jo...@8b...> Cc: Paul Gortmaker <pau...@wi...> Cc: Greg Kroah-Hartman <gr...@li...> Cc: Benjamin Herrenschmidt <be...@ke...> Cc: Grant Likely <gra...@li...> Cc: Rafael J. Wysocki <rj...@rj...> Cc: Bjorn Helgaas <bhe...@go...> Cc: Randy Dunlap <rd...@in...> Cc: Yinghai Lu <yi...@ke...> Cc: Len Brown <len...@in...> Cc: Pavel Machek <pa...@uc...> Link: http://lkml.kernel.org/r/140...@li... Signed-off-by: Thomas Gleixner <tg...@li...> :040000 040000 e2ffe2a09062cc3fd40f2367a3f5e47fe3852277 9b690563070c3d0de56a9c950e32cb2def10d08f M arch On Sun, Oct 19, 2014 at 1:40 PM, Daniel Robbins <dro...@fu...> wrote: > And I will start a bisect between 3.16.0 and 3.17.0 and see what is causing > this.... > > -Daniel > > On Sun, Oct 19, 2014 at 1:16 PM, Daniel Robbins <dro...@fu...> wrote: >> >> This board only has one PCI slot, and I believe it is using the latest >> BIOS. >> >> I am attaching dmesg from 3.16.0, where the firewire card is handled just >> fine (using it to listen to music right now :) I am curious why it works >> fine with 3.16.0 and not with 3.17.0+. >> >> -Daniel >> >> On Sun, Oct 19, 2014 at 1:10 PM, Clemens Ladisch <cl...@la...> >> wrote: >>> >>> Daniel Robbins wrote: >>> > [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 20 low >>> > level) >>> > [ 2.699224] firewire_ohci 0000:06:00.0: failed to allocate interrupt >>> > 20 >>> >>> Interrupt 20 is actually interrupt 9, which is already used for ACPI >>> events. >>> (At least this is what the kernel thinks what the BIOS tells it.) >>> >>> In theory, the controller's "20" is bus_irq, which should not conflict. >>> Could you bisect the kernel? >>> >>> Is this a controller card which you could plug into a different slot? >>> Or could you update the motherboard BIOS? >>> >>> >>> Regards, >>> Clemens >> >> > |
From: Daniel R. <dro...@fu...> - 2014-10-19 19:40:13
|
And I will start a bisect between 3.16.0 and 3.17.0 and see what is causing this.... -Daniel On Sun, Oct 19, 2014 at 1:16 PM, Daniel Robbins <dro...@fu...> wrote: > This board only has one PCI slot, and I believe it is using the latest > BIOS. > > I am attaching dmesg from 3.16.0, where the firewire card is handled just > fine (using it to listen to music right now :) I am curious why it works > fine with 3.16.0 and not with 3.17.0+. > > -Daniel > > On Sun, Oct 19, 2014 at 1:10 PM, Clemens Ladisch <cl...@la...> > wrote: > >> Daniel Robbins wrote: >> > [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 20 low >> level) >> > [ 2.699224] firewire_ohci 0000:06:00.0: failed to allocate interrupt >> 20 >> >> Interrupt 20 is actually interrupt 9, which is already used for ACPI >> events. >> (At least this is what the kernel thinks what the BIOS tells it.) >> >> In theory, the controller's "20" is bus_irq, which should not conflict. >> Could you bisect the kernel? >> >> Is this a controller card which you could plug into a different slot? >> Or could you update the motherboard BIOS? >> >> >> Regards, >> Clemens >> > > |
From: Clemens L. <cl...@la...> - 2014-10-19 19:10:32
|
Daniel Robbins wrote: > [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 20 low level) > [ 2.699224] firewire_ohci 0000:06:00.0: failed to allocate interrupt 20 Interrupt 20 is actually interrupt 9, which is already used for ACPI events. (At least this is what the kernel thinks what the BIOS tells it.) In theory, the controller's "20" is bus_irq, which should not conflict. Could you bisect the kernel? Is this a controller card which you could plug into a different slot? Or could you update the motherboard BIOS? Regards, Clemens |
From: Clemens L. <cl...@la...> - 2014-10-16 17:48:54
|
Daniel Robbins wrote: > Okay, nothing else on IRQ 20, which is why it is so odd. Please show the entire boot log. Regards, Clemens |
From: Daniel R. <dro...@fu...> - 2014-10-10 14:51:38
|
Okay, nothing else on IRQ 20, which is why it is so odd. Yes, and essentially no change to the firewire code since 3.16.0. Hmmm. 06:00.0 FireWire (IEEE 1394) [0c00]: Texas Instruments TSB82AA2 IEEE-1394b Link Layer Controller [104c:8025] (rev 01) (prog-if 1 0 [OHCI]) Subsystem: Texas Instruments TSB82AA2 IEEE-1394b Link Layer Controller [104c:8025] Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Interrupt: pin A routed to IRQ 20 Region 0: Memory at fbffb800 (32-bit, non-prefetchable) [size=2K] Region 1: Memory at fbffc000 (32-bit, non-prefetchable) [size=16K] Capabilities: [44] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Kernel modules: firewire_ohci plex drobbins # cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 0: 126 0 0 0 IO-APIC-edge timer 1: 1 0 0 2 IO-APIC-edge i8042 8: 0 0 0 66 IO-APIC-edge rtc0 9: 0 0 0 0 IO-APIC-fasteoi acpi 12: 0 0 0 4 IO-APIC-edge i8042 18: 0 0 0 0 IO-APIC 18-fasteoi i801_smbus 21: 0 72 0 0 IO-APIC 21-fasteoi ehci_hcd:usb1 23: 0 0 34 0 IO-APIC 23-fasteoi ehci_hcd:usb2 24: 38508094 0 0 0 HPET_MSI-edge hpet2 25: 0 36516288 0 0 HPET_MSI-edge hpet3 26: 0 0 36180322 0 HPET_MSI-edge hpet4 27: 0 0 0 34039186 HPET_MSI-edge hpet5 29: 0 0 0 0 DMAR_MSI-edge dmar0 30: 0 0 0 0 PCI-MSI-edge aerdrv 31: 0 0 0 0 PCI-MSI-edge aerdrv 35: 308716 0 0 0 PCI-MSI-edge ahci 36: 499296 0 0 0 PCI-MSI-edge eth0-rx-0 37: 0 472843 0 0 PCI-MSI-edge eth0-tx-0 38: 0 0 2 0 PCI-MSI-edge eth0 NMI: 0 0 0 0 Non-maskable interrupts LOC: 87 76 62 50 Local timer interrupts SPU: 0 0 0 0 Spurious interrupts PMI: 0 0 0 0 Performance monitoring interrupts IWI: 0 0 0 0 IRQ work interrupts RTR: 3 0 0 0 APIC ICR read retries RES: 23366853 23172156 22929406 21895431 Rescheduling interrupts CAL: 11038985 10976238 10966038 10848531 Function call interrupts TLB: 453 1144 929 937 TLB shootdowns TRM: 0 0 0 0 Thermal event interrupts THR: 0 0 0 0 Threshold APIC interrupts MCE: 0 0 0 0 Machine check exceptions MCP: 209 209 209 209 Machine check polls ERR: 0 MIS: 0 On Fri, Oct 10, 2014 at 1:09 AM, Takashi Sakamoto <o-t...@sa...> wrote: > On Oct 10 2014 16:06, Clemens Ladisch wrote: >> >> Daniel Robbins wrote: >>> >>> With kernel 3.17.0, it now looks like firewire-ohci is misbehaving: >>> >>> [ 2.723177] firewire_ohci 0000:06:00.0: failed to allocate interrupt >>> 20 >>> [ 2.723206] firewire_ohci: probe of 0000:06:00.0 failed with error -5 >>> >>> 3.16.0 worked with your fixes... now that the fixes are in 3.17.0, >>> firewire-ohci appears broken. >> >> >> This has nothing to do with the sound driver. > > > Indeed. > >> Please show the "lspci -nnvv" entry of the controller, and the entire log. >> Is there any other driver on IRQ 20? > > > Output from /proc/interrupts will be our help, too. > > > Regards > > Takashi Sakamoto > o-t...@sa... |