Activity for Julian Cable
-
Julian Cable posted a comment on discussion Help Compiling
My Mac is a company one and our latest supported OS is Monterey. Have you tried the homebrew recipe? – its old but could be updated. https://github.com/jcable/homebrew-dream Julian From: discussion@drm.p.re.sourceforge.net discussion@drm.p.re.sourceforge.net on behalf of Mark J. Fine fineware@users.sourceforge.net Date: Sunday, 18 December 2022 at 01:32 To: Julian Cable julian.cable@bbc.co.uk Subject: [drm:discussion] Re: macos Ventura and other adventures building on M1 Macs "Apparently Qt under...
-
Hi Mark, thanks for a REALLY helpful situation report. I’m afraid I failed abysmally the last time I tried building on Windows. By contrast a MacOs build using a homebrew recipe worked like a dream. QtMultimedia used to be in Qt5 – have they changed that? Oh dear. We had huge problems moving from Qt2 to Qt3 and pretty much every major version. If we could find a Windows savvy volunteer to help that would be wonderful. With the fantastic work Ollie has done recently on Dream, it would be great to...
-
Here is a good link: https://gist.github.com/onetransistor/4cbe3a8ab5d47da22cde This is the key line to make sure the DRM options are invoked: ./configure --with-pic --enable-shared --without-mp4v2 --enable-drm
-
Probably the faac you have downloaded was not compiled with the right flags. It looks like the old wiki is down again - that had good instructions. I'll see what I can do.
-
Faad is the decoder. You need faac or fdk to encode. I can't remember how well integrated fdk is, best to play with faac. I'll ask Ollie. Remember faac is horrible and horribly patent encumbered. Use at your own decision. Julian Get Outlook for Androidhttps://aka.ms/AAb9ysg From: discussion@drm.p.re.sourceforge.net discussion@drm.p.re.sourceforge.net on behalf of rory bushell arclamp@users.sourceforge.net Sent: Tuesday, October 4, 2022 12:46:18 AM To: Julian Cable julian.cable@bbc.co.uk Subject:...
-
qmake (or the dream.pro) tries to detect what packages are installed and use them so if you apt-get install pulseaudio-dev (or the right thing if I've remembered that wrongly) it will probably pick pulse. Generallising out of the hack needs a little thought. Ollie and I will try and make time to at least come up with a direction of travel..
-
Hi all, as Ollie says, we're really happy for your interest on this work. Just so you know, Ollie has been a major player in DRM from the very start and his team in BBC R&D were responsible for some of the earliest working content servers and receivers. No-one understands the signal processing in DRM the way Ollie does. We're privileged to have him working on a new Dream based DRM monitoring solution and we are doing it in a way which gives the maximum benefit to the whole professional and amateur...
-
is that a dream menu? If it is I'd forgotten about it. But AAC mono and Precoded are not greyed out. AAC mono is all FAAC can do - they never implemented SBR in FAAC, only in FAAD2 and the fdk so this looks like its working. We looked at adding CELP and HVXC but then they took them out of the standard when they put xHE-AAC in.
-
is that a dream menu? If it is I'd forgotten about it. But AAC mono and Precoded are not greyed out. That's all FAAC can do - they never implemented SBR in FAAC, only in FAAD2 and the fdk so this looks like its working. We looked at adding CELP and HVXC but then they took them out of the standard when they put xHE-AAC in.
-
From memory, that's a fundamental limitation of FAAC. Dream will be the same.
-
Then you don't really need the dream transmitter. By the way, there is a DRM capable FAAC binary buried in the Spark code - it might be a 64 bit dll and you might be able to dig it out.
-
Also if you really want to transmit, or experiment with DRM's full content capability, you would be much better using Michael's Spark software as the transmitter and Dream as the receiver. https://www.drm-sender.de/?page=history&lang=en Dream's transmitter is just the bare minimum implementation to allow bench testing of the receiver.
-
Are you using this one: https://sourceforge.net/p/drm/discussion/codec/thread/3999cec3/#81f6 ? Is you Windows 32 bit or 64 bit? Stefano says the libfaac.dll only works on 32 bit machines. If yours is 64 (most are these days) then you will need to compile the codec yourself. Or if you just want to experiment, you can use the Opus codec. No real DRM receiver will be able to decode your transmissions but your own dream will. Or experiment with slide shows first.
-
ok these are the allowed names of the dll { "faac_drm.dll", "libfaac_drm.dll", "libfaac.dll", "faac.dll", nullptr }; so yours is ok. let me see if i can find another copy
-
sorry - l don't have a working windows machine. I'll check the names dream is looking for faac as.
-
Oh dear, Windows isn't capturing the output. Stupid operating system :( can you list the directory ? I want to make sure faac.dll (or whatever it's called) is in there. Can you also confirm what version of dream you are using - I presume its a compiled one from the files area - is it 2.2?
-
Oh dear, Windows isn't capturing the output. Stupid operating system :( can you list the directory ? I want to make sure faac.dll (or whatever it's called is in there. Can you also confirm what version of dream you are using - I presume its a compile one from the files area - is it 2.2?
-
I won't be able to respond for the next 8 hours. Funny thing called work ...
-
so if you open a command line and cd to the directory where dream.exe is and type dream -t you should see some logging.
-
sorry, I just meant to run it from the command line. What operating system are you using?
-
Can you run from the command line and capture what gets printed and post it?
-
I think there is some code there for that but I can't remember in which branch. I don't have any time to do this but if anyone wants to have a go I'll make time to review and publish it.
-
Thanks Mark – bizarrely I found similar things this week. The first time I’ve tried compiling Dream in a long time. I didn’t spot the qwt_text issue but I also found a libgps one. Unfortunately these are very library version specific – I made changes to compile on my mac using homebrew and had to back out of ½ of them on ubuntu. I’ll try and make them library version specific. I might manage it this weekend. Julian From: "Mark J. Fine" fineware@users.sourceforge.net Reply to: "[drm:discussion]" compiling@discussion.drm.p.re.sourceforge.net...
-
compiles
-
ubuntu
-
libgps updates
-
add branch
-
Sorry, FAAC is the only DRM capable encoder and it is so patent and copyright encumbered that we’ve never been willing to provide a compiled version. There are instructions for compiling that are fairly bulletproof. What operating system are you using? I’m afraid I failed totally the last time I tried to build dream on Windows and I don’t have a windows machine to try it on. But there are old Visual Studio project files in the files area for building FAAC in a DRM compatible way. Julian From: rory...
-
Thats amazing!!! I'll try and find some time on Sunday to review and adopt this into the system. Thanks everyone!
-
I'm pretty sure the FDK decoder works. The problem is the sliding superframe which I know roughly how to handle but haven't found time to get working. The superfame is at section 5.3 here: https://www.etsi.org/deliver/etsi_es/201900_201999/201980/04.01.02_60/es_201980v040102p.pdf
-
What did you change to fix the UI? I can give you write access to subversion if you want to create a branch and submit code, or just attach changed files here.
-
That's the perfect output - thanks! I'll have a look.
-
It's not AAC+ its xHE-AAC. but yes, India is using the new codec we haven't quite got working yet.
-
Thanks, if debug is different from release it is usually an uninitialised variable but it would be even more useful if you could step through the programme and let me know what line it crashes on. Also can you post the output of qmake so I know for certain which libraries are being pulled in. FYI the sound card code has changed somewhat, to try and take advantage of changes between windows 95 and windows 10. It is obviously still work-in-progress. I couldn't get the QAudio version working on Windows,...
-
Thats helpful. Could you run a debug build and see if we get any better information such as a line number or the kind of exception that is thrown?
-
The Dream 2.2 branch is relatively stable for AAC decoding. When I get some time I want to finish the xHE-AAC decoder. 2.2 works well on OSX and can work OK on linux although I'm still not sure what the best audio driver should be. But we have this nasty build problem on Windows 10. If anyone can help make a build and an installer that will make working Windows 10 installs easy it would be really helpful. Julian
-
FYI Dream supports the Opus codec, its just not part of the standard so it isn't used by any broadcasters. I'll see what I can do about getting Dream 2.2 to work on Windows 10 properly, Its a very strange problem and I never use windows so its not an easy one for me to fix.
-
Hi Dave, sorry for the slow response. I'd go with https://drm.sourceforge.io/wiki/index.php/Building_on_Mac_OSX. It should be perfectly possible to build using XCode but those instructions are old and I notice it gave you a Qt4 build whereas only Qt5 is likely to work well when building. I have QTCreator building the dream-2.2 branch on Mohave. I also have an experimental brew tap for dream. Try: brew tap jcable/dream brew install dream Julian
-
I'm pretty sure it is. I've heard the odd snippet of decoded audio in my test system but Dream still needs significant development to decode a real stream - mostly because of the sliding audio super-frame in the xHE-AAC. I'm maxed out on other things at the moment an unable to spend any time coding.
-
try https://www.rtl-sdr.com/tutorial-drm-radio-using-rtl-sdr/ or the latest 2.2 build doesn't need faad2 as it uses the new fdk-aac codec but it's not really working for everyone yet.
-
Hi Ronald. I don't have a Windows machine to hand but can I just check you want to transmit? You don't need FAAC for just listening.
-
Hi Jon, sorry for the slow response at the moment. I'm on holiday in Ireland. I've added you to the developer list so you should be able create tickets. I'm very confused by the highly varying capture behaviour as things haven't changed much at this end ever. I think there have been recent behaviour changes to the underlying Linux drivers. Or perhaps sound cards have smaller buffers these days, or it could be related to the locking and tick changes to the Linux kernel itself since the original code...
-
No it is just a prototype. It's on the wish list.
-
Thanks. I looked it up and I'll try and include in future.
-
xHE-AAC needs new code. The audio frames are totally asynchronous to the audio super frame. Dream isn’t set up for that. It expects a fixed number of complete audio frames per audio superframe. I know how to fix it but it’s for after we fix the basics. Sent from my iPhone On 9 May 2019, at 01:03, Mark J. Fine fineware@users.sourceforge.net<mailto:fineware@users.sourceforge.net> wrote: I used to do a little signal processing. Almost seems like a lifetime ago. I'll probably check r1331 tomorrow. I'll...
-
I'm not an expert on the signal processing but the Multi-Level Coding iterations must be something to do with decoding the QAM constellations. More iterations means more chance to put the symbols in the correct box. I did a full re-code of the sound input loop in CReceiveData and then I did another one using event driven inputs. They both seem to work on MacOs and the blocking loops works better on Linux than previous versions (I haven't tried the event driven option on Linux). Give them a go. -r...
-
dormant code using event driven audio input - seems to work but needs
-
better but aac decode seems broken
-
qt multimedia experimentation
-
You are definately onto something. It explains why I get fewer problems when I'm mostly using the file input. I'll have a think but it should already be the case that almost all QtMM (and any other sound interface) actions happen in the working thread. I've already worked quite hard with slots and signals (and the new CRx class) to force this, although as you say, the timer errors indicate there is more to do. I'll have a look at those buffer size discrepancies. We may be able to force things to...
-
try without DLL_EXPORT variable
-
try without DLL_EXPORT variable
-
portaudio enum update
-
2.2 tag r1325 has another go at the qtmultimedia IO in both creceivedata and DataIO. I went back to the docs and did it from scratch and moved the start function call into InitInternal so it knows the required buffersize. Let me know what you think. J
-
improve soundnull
-
QtMultimedia improvements.
-
match new Enumerate call
-
add QAudioOutput field
-
QtMultimedia improvments for sound output from receiver
-
quiet warning
-
That's all good - its a bit scary coding 'in public' but its the only way to get the the help one needs. I still find dream's pipeline code really hard to work out how the buffers fill. Your help is hugely appreciated.
-
fix compile using mxe on Ubuntu
-
Would be senible to be able to do this from the evaluation dialogue. Also a CLI parameter.
-
Control output volume from within dream
-
Control input gain from within dream
-
Reading your DataIO code I don't think it ought to be right. Have a read of https://doc.qt.io/qt-5/qiodevice.html#writeData. As I (now) understand it QIODevice::write is the interface for writeData which is the implementation. So the comments about writeData not needing to be called more than once apply to write. So your loop isn't correct. If you look at my current code it uses a loop but only because the buffer that comes from the decoder might be bigger than the one in the sound card driver. Note...
-
Hi, please report failures and successes with linux here: https://sourceforge.net/p/drm/tickets/230/
-
Hi, please report successes and failures with windows 7 here: https://sourceforge.net/p/drm/tickets/226/ . Please report successes and failures with windows 10 here: https://sourceforge.net/p/drm/tickets/227/
-
Milestone▾ Status▾ Owner▾ Created▾ Updated▾ 230 Problems on Linux 2.2 accepted Julian Cable 10 seconds ago 10 seconds ago 229 Improve default sound card selection when none saved in Dream.ini 2.2 closed Julian Cable 1 minute ago 1 minute ago 228 Fix alsa driver 2.2 closed Julian Cable 4 minutes ago 4 minutes ago 227 Problems on Windows 10 2.2 open 6 minutes ago 5 minutes ago 226 problems on Windows 7. Hi, please report successes and failures with windows 7 here: https://sourceforge.net/p/drm/tickets/226/...
-
Problems on Linux
-
Improve default sound card selection when none saved in Dream.ini
-
Fix alsa driver
-
See also https://sourceforge.net/p/drm/discussion/general/thread/89a7d6fc8f/#d792
-
Problems on Windows 10
-
problems on Windows 7.
-
just noticed your comment about qt.conf - can you explain this one? You have a piece of Qt understanding I'm missing and I can hopefully incorporate it into the build. Julian
-
Add support for timed slide shows and other 2.2.1 features.
-
Allow decoding of multiple simultaneous data streams
-
Link sound input selection to rig selection
-
Support 100 ms as well as 400 ms transmission frames
-
It should be possible to rolle this into the support needed for xHE-AAC.
-
Support Mode E modulation
-
Support Mode E RSCI
-
Add support for SoapySDR
-
Extend rig data structures to indicate channel and sample rate requirements.
-
Add support for QtMultimedia
-
Live schedule (AFS) and Stations Dialogue should share more code
-
Tablet / Phone friendly GUI
-
Support Mode E demodulation
-
Stations Dialog - Frequency picker not rendered well on Snow Leopard
-
too old
-
Make Funcubedongle Pro+ work on Android
-
Or use SoapySDR? https://github.com/pothosware/SoapySDR/wiki
-
Tuning support for FCDP+
-
or use SoapySDR? https://github.com/pothosware/SoapySDR/wiki
-
Now supported in fdk-aac v2.
-
Simplify installation of AAC codecs for windows
-
We don't need this now we have fdk-aac.
-
Implement Qt Positioning as an alternative to libgpsd
-
Can't use port filtering with file open
1 >
